Question

来自git 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次提交放入临时区域
依次将已经完成的提交到具有相同状态的repo
结束

但是我得到一个错误：

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会存储每次文件外观的快照。这意味着，如果在重定基中存在任何合并，则它不知道该怎么做-在重定基合并时，git有三个不同的文件系统要比较，并且需要一些指导（在这种情况下，启发式'使其看上去就像链中的下一个链接一样很好，但这是一个极端的情况）。

要解决所示的示例，请使用'--preserve-merges'开关解决此问题。

当git重新定位到同一分支时，如何发生合并冲突？

1 个答案: