Question

我刚做了git pull --rebase origin master并且发生了冲突。

首先，这个冲突发生在一个我没有碰过的文件中，大约有10个提交回来了。为什么会这样？

然后我意外地输入了git rebase --skip，并且'跳过了那个补丁'。

担心我跳过了一个提交，我检查了一个新版本的master分支，并在我做了rebase的分支和新的master分支之间做了一个差异。 diff中显示的唯一更改是最新提交，查看日志，“已跳过”的修补程序显示在提交历史记录中。

有谁能解释这里发生了什么？

Answer 1

它按照它说的做，它跳过提交。如果您在同一个rebase期间在以后的冲突中运行rebase --abort，那么当然也会恢复跳过的提交。

如果您的更改已存在于上游，Git将无法应用您的提交（但通常应自动跳过它，如果修补程序完全相同）。您将自己的提交被跳过，但更改仍将存在于当前的HEAD中，因为它已经应用于上游。

你应该确保你没有删除你的重要更改;）（使用reflog返回到rebase之前的状态）

Answer 2

当我知道不应该有任何冲突并且列出的冲突没有任何意义时，我经常自己碰到这个问题。例如，我有几个分支，如下所示：

A --> B --> C --> D --> E ...

分支 D 中的修改之一是添加一个文件，我意识到在分支 B 中添加该文件更有意义。所以我这样做了

  git switch B
  git checkout B -- path/to/new/file
  git commit --amend --no-edit

然后我做到了

  git switch C
  git rebase B

这很好，但当我这样做时

  git switch D
  git rebase C

有冲突。我能够手动修复它，但我也发现我可以

  git rebase --skip

一切都很好。然后当我这样做

  git switch E
  git rebase D

发生了同样的冲突。同样，我可以手动修复它或跳过它以得到相同的结果。

我仍在努力弄清楚为什么有时会发生这些冲突以及为什么有时会起作用

  git rebase --skip

在这种情况下。