意外的git合并冲突

3

所以我有一个包含三行的简单文件:

some
random
words

第一次合并测试

我从主分支创建了两个不同的分支,文件在本帖顶部处于原始状态。我创建了名为merge1的分支,将第一行从some更改为will。我创建了名为merge2的分支,将第三行从words更改为work。我首先合并merge1,然后再合并merge2到主分支中,一切都按预期正常工作。

第二次合并测试

我从主分支创建了两个不同的分支,文件在本帖顶部处于原始状态。我创建了名为merge1的分支,将第一行从some更改为doesnt。我创建了名为merge2的分支,将第二行从random更改为work。我首先合并merge1,这很好地完成了,但是当我尝试合并merge2时,出现了意外的冲突错误。

当我打开文件时,看到的是:

<<<<<<< HEAD
doesnt
random
=======
some
work
>>>>>>> merge2
words

我不理解的是为什么merge2显示第一行为some,因为merge2没有改变那行。这讽刺的是SVN可以很好地处理这个问题。
我错过了什么吗?为什么我可以从同一个提交创建的两个不同分支轻松修改小文件的不同行,但不能更改连续的行?

3
个人而言,我发现默认的冲突样式完全无法阅读。尝试使用git config --global merge.conflictstyle diff3命令。这可能会更有意义。同时请注意,合并是通过应用补丁(类似于Unified Diff格式)来完成的,这意味着在这样一个小的测试中,可能没有足够未改变的上下文行来确定需要更改的内容。 - Will Palmer
谢谢你提供有关conflictstyle的提示,它确实提供了更多信息,使我们能够更好地决定如何处理冲突。我也明白这个文件的范围很小,最初在一个6000行的文件上遇到了问题,但认为在stackoverflow上提问会更好。 - ryanzec
1个回答

5

根据对git的使用经验,以下是一些猜测...

变更是基于其周围环境进行跟踪的。如果您查看merge2提交的diff,它将类似于:

 some
-random
+work
 words

当您尝试将其合并到由merge1修改的文件中时,它无法找到锚点“some”。 因此,它需要询问您如何继续。 然而,当您修改非连续行时,它仍然可以在文件中找到一些地方来锚定需要应用的更改。
此外,请记住,git旨在追踪代码更改。 它倾向于在合并时保持谨慎,因为最好让用户弄清楚合并而不是自动合并并以某种不明显的方式破坏代码。

1
代码更改和破坏的问题提出得很好...这使得SVN自动合并这一事实有点可怕! :) - Wildcard

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接