修复冲突后git rebase

Question

有时我在重新定基础并解决冲突后遇到了这个问题。 我做了git add . 我将运行git rebase --continue 。

但是，有时我会收到此消息

Applying: xxxxxx
No changes - did you forget to use 'git add'?
If there is nothing left to stage, chances are that something else  
already introduced the same changes; you might want to skip this patch.

我不知道为什么会这样。 所以，我最后只是做git rebase --skip来进行。 谁能告诉我为什么Git没有意识到我解决了冲突？

Answer 1

Git的作者认为这是一个很好的安全装置，并不是说Git没意识到您已经解决了冲突。

这种情况发生在您选择樱桃的提交时（请记住git rebase不管是有效还是实际上只是很多重复的樱桃选择），而该更改与已经存在的更改并不完全相同 ，但非常相似 ，您所依据的提交。

例如，假设原始工作是这样的：

...--o--*           <-- origin/develop
         \
          A--B--C   <-- develop

在这里， A ， B和C是您所做的三个提交。 提交*是您刚开始develop时所处的位置，而origin/develop仍会记住它。

在提交A ，您修复了文件a ，并更新了README.txt文件。 在B ，您修复了文件b某些内容，但是忘记更新README.txt 。 在提交C您记得要更新README.txt所以您要这样做。

现在，其他人进行了更改并将其推送到您的上游服务器，因此您git fetch 他们的工作：

...--o--*--D--E     <-- origin/develop
         \
          A--B--C   <-- develop

然后去到git rebase的develop在新的origin/develop 。 通常，这会将A ， B和C 复制到新的提交A' ， B'和C'因此，如果一切顺利，您将得到：

...--o--*--D--E            <-- origin/develop
         \     \
          \     A'-B'-C'   <-- develop
           \
            A--B--C        [abandoned]

新的A'-B'-C'提交只是原始git cherry-pick副本。

Git非常聪明，如果您的提交A引入了与 D或E 完全相同的更改 ，则Git在复制时会简单地删除 A ：它将跳过它并仅复制B和C 但是，假设从这个意义上说A “等于” D ，或者（出于论证的理由，第二种情况是正确的）， A是完全独立的并且可以被复制。 但是，它既不B 也不 C说，“平等” E ，而是总和， B+C ，即“平等” E 。 也就是说，您和他们进行了相同的修复，但是他们记得一次提交中修复了README.txt ……并且对文件b的更改存在一些细微的拼写差异-或文件b已重新格式化或采用某种格式，从而保持了Git照原样应用您的更改。

当Git试图挑选B成为B'您可以手工解决Git抱怨的b任何问题。 然后您git add已解析的文件。 但是现在您的文件b与上游b完全匹配。 尽管这样做是有目的的-毕竟没有什么可提交b ，但Git不知道您已经验证了这一点。 Git认为您可能只是运行git checkout HEAD -- b来查看其版本。 这将提取他们的 b并假装一切都解决了，否则您将处于相同的情况。 ¹

因此，由于这将完全删除您的提交B ，因此Git会向您发出此警告。 如果正确的事情是现在完全删除提交B ，则应该毕竟运行git rebase --skip ，然后跳过B

Git现在将尝试应用您的C来修复README.txt 。 这将不需要做任何事情，因为他们已经在提交D做到了。 您的Git会再次看到，在解决了冲突（也许甚至是自动的）之后，没有任何可提交的内容。 Git会想知道是否可能出错，然后让您运行git rebase --skip来确认这是正确的。

完成后，事实证明只需要复制A ，实际上您得到的是：

...--o--*--D--E       <-- origin/develop
         \     \
          \     A'    <-- develop
           \
            A--B--C   [abandoned]

但是Git 确实要确保从复制中省略B和C是正确的，因为在运行git rebase --continue时，很容易忘记字面上的git add是相对容易的。

---

^1，如果你意识到这一点，很早就上的Git 没有一个很好的内置这可能是更明智git cherry-pick命令。 取而代之的是，重新定基将提交变成补丁，然后尝试应用补丁，就像有人将其邮寄给您一样。 然后，Git将无法告诉您是否只是忘记应用补丁。