git - 修复冲突后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不知道我解决了冲突？

Answer 1

与其说git没有意识到您已经修复了冲突，不如说git的作者认为这是一个很好的安全设备。
当您正在选择提交时，就会发生这种情况，请记住git rebase无论是有效的还是实际的，只是大量重复的选择-这种更改与您正在重新调整的提交中已经发生的更改不完全相同，但非常相似。
例如，假设最初的工作是这样的：

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

这里 A、 B和 C是您所做的三次提交。commit *是您刚开始时 develop所在的位置，并且 origin/develop仍然记得它。
在commit A中，修复文件 a中的某些内容，并更新 README.txt文件。在 B中，您修复了文件 b中的某些内容，但忘记更新 README.txt。在commit 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]

新的提交只是原始提交的拷贝。
git非常聪明，如果您的commit A'-B'-C'引入的更改与 git cherry-pick或 A中的更改完全相同，那么git在复制时只需删除 D：它将跳过它，只复制 E和 A。但假设从这个意义上说，要么 B“等于” C，要么假设第二种情况是真的- A是完全独立的，并且可以很好地复制。但是，既不是“等于”也不是“等于”，而是“等于”的和。也就是说，你和他们做了同样的修复，但是他们记得在一次提交中修复了 D。他们对file A的更改有一些细微的拼写差异，或者file B被重新格式化了，或者其他什么，使git无法按原样应用更改。
当git试图选择commit C来创建 E时，您可以手动解决git所抱怨的 B+C问题。然后您将 E解析的文件。但现在您的文件 README.txt与上游的 b完全匹配。虽然这是故意的，但在git不知道您已经验证了这一点之后，对file b没有任何影响。Git认为也许你只是运行 b来查看他们的版本。这将提取他们的 B并假装所有问题都已解决，否则将使您处于相同的情况下。1
因此，由于这将完全删除您的commit B'，git会给您这个警告。如果正确的做法是现在完全放弃提交，那么毕竟应该运行 git add，跳过 b。
Git现在将尝试应用您的 b来修复 b。这不需要做任何事情，因为他们已经在commit git checkout HEAD -- b中做了。您的git将再次看到，在解决了甚至可能是自动解决后，这次的冲突，没有什么可提交的。git会怀疑它是否搞错了，并让您运行 b来确认这是正确的。
一旦完成，结果发现只需要复制 B，而实际上您最终会得到：

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

但是git想确定从拷贝中省略 B和 git rebase --skip是正确的，因为在运行 B时很容易忘记 C。
1如果您很早就意识到git没有一个好的内置 README.txt命令，那么这可能更有意义。相反，rebacking将提交转换为修补程序，然后尝试应用修补程序，就像有人将其邮寄给您一样。然后git将无法判断您是否忘记应用补丁。