当git重新绑定到同一个分支时，怎么会出现合并冲突？

Question

来自gaz rebase的the documentation：

当前分支被重置为，或者如果提供了--onto选项。这与git reset --hard（或）具有完全相同的效果。 ORIG_HEAD设置为在重置之前指向分支的尖端。

之前保存到临时区域的提交将按顺序逐个重新应用于当前分支。注意，HEAD中引入与HEAD中的提交相同的文本更改的任何提交都被省略（即，将跳过已经在上游接受具有不同提交消息或时间戳的补丁）。

然后重要的一点：

合并失败可能会阻止此过程完全自动化

我可以看到一般情况如何发生，但我有一个案例似乎发生了奇怪的事情。

这是我的命令：

407  07/09/18 16:53:09 cd temp
  408  07/09/18 16:53:16 git clone https://github.com/joereddington/todo.txt
  410  07/09/18 16:53:35 cd todo.txt/
  412  07/09/18 16:53:41 git rebase HEAD~20

我觉得这不可能失败。我的理解是，顺序是：

• 将HEAD移动到HEAD~20
• 将最近的20个提交放入临时区域
• 按顺序，重新应用已经对具有相同状态的仓库进行的提交
• 结束

但是我收到一个错误：

Applying: update Using index info to reconstruct a base tree... M   todo.txt .git/rebase-apply/patch:21: trailing whitespace. (A) Apply for gift aid number  .git/rebase-apply/patch:30: trailing whitespace. (C) Sort all the 'to sort' spending in the right categories in the expenditure against grant file.  .git/rebase-apply/patch:76: trailing whitespace. (E) Go thought calendar and find at least one 'thank you's you *can* make  warning: 3 lines add whitespace errors. Falling back to patching base and 3-way merge... Auto-merging todo.txt CONFLICT (content): Merge conflict in todo.txt error: Failed to merge in the changes. Patch failed at 0025 update The copy of the patch that failed is found in: .git/rebase-apply/patch

Resolve all conflicts manually, mark them as resolved with "git add/rm <conflicted_files>", then run "git rebase --continue". You can instead skip this commit: run "git rebase --skip". To abort and get back to the state before "git rebase", run "git rebase --abort".

Josephs-Mini:todo.txt josephreddington$

怎么会发生这种情况？它拒绝对已经执行相同更改的内容执行提交！

Answer 1

此问题基于对版本控制系统的过时理解。

像CVS和SVN这样的系统将提交存储为增量 - 提交实际上是与先前版本的差异列表。如果git以相同的方式工作，那么这种变基将完全没有错误是有意义的。

Git不能那样工作（有some delta compression under the hood）。 Git存储每次文件外观的快照。这意味着如果在rebase中有任何合并，那么它不知道如何处理它们 - 当重新定义合并git有三个不同的文件系统要比较并想要一些指导（在这种情况下是启发式的'让它看起来完全像链中的下一个链接'会很好，但这是一个边缘情况）。

为了解决所提出的示例，交换机' - preserve-merges'解决了这个问题。