导致git合并冲突的原因和案例是什么？

Question

1. 是什么

   • 必要和充分的条件,和/或

   • 所有案件或一些常见案件

   那可能导致 git merge报告合并冲突？

   如何git merge确定某条线或某些线是否包含合并冲突？

2. 例如,我有时会看到如下情况,其中 Part 1或者Part 2是空的

   <<<<<<< HEAD
   (Part 1)
   =======
   (Part 2)
   >>>>>>> some-other-branch
   

   它看起来不太可能与我发生合并冲突.那么像这样的案例有合并冲突的可能原因是什么？

3. 比较报告的合并冲突git merge 和报告的差异git diff是否正确

   • 报告的差异git diff可能不一定在报告的合并冲突的地方git merge,和

   • 报告的合并冲突git merge可能不一定是在报告的差异的地方git diff？

谢谢.

Answer 1

完整,正确的答案有多个部分.首先,我们必须首先进行正常的三向合并(在Git中需要使用-s recursive或者-s resolve,如果使用-s recursive,则查找单个合并基础和另外两个提交).但是,您可能希望跳到第三部分.

正常三向合并所需的元素

要进行任何合并,您需要:

• 一个合并基础提交乙,¹
• 当前提交L(左侧,又名HEAD),其中B为祖先,
• 另一个提交R也有B作为祖先.

由于"是祖先"允许在提交图形节点平等(技术上它是一个前身-或等于≼比较),它可能有乙= L和/或乙= R.如果是这种情况,然而,则没有合并是不断需要,如果你做强制合并(使用git merge --no-ff-这意味着乙= L和大号≺[R ;两个非受迫性案件"快进"不实际-A-合并和"没有合并"错误)将没有合并冲突.因此我们可以假设合并基础在合并的两侧之前.

¹使用--allow-unrelated-histories,如果L和R没有最低的共同祖先节点,则可以在空树中使用Git替换实际的基本提交.但是,这会导致所有标识的文件添加/添加冲突.

给定合并,冲突所需的元素

接下来,要在某个文件路径中发生冲突,您需要我称之为"高级别"冲突或"低级别"冲突(或两者).为此,Git必须识别(即匹配)B,L和R中的文件.由于能够添加新文件,重命名文件和删除文件,因此不要求文件在所有三次提交中具有相同的名称.特别是:

• 如果路径P存在于B,L和R的所有三个中,则具有路径P的三个文件被一起识别.(也就是说,有一个路径P _B,例如path/to/foo.txt,具有匹配的P _L path/to/foo.txt和P _R. path/to/foo.txt显然,这个文件在整个合并过程中都是"同一个文件",因此Git将这三个路径标识为一个文件.)
• 或者,可能有多达三个不同的路径,P _乙 path/to/basename,P _大号 path2/to2/left,和P _{- [R} path3/to3/right.这些中的一个或多个可能甚至不存在.这些结果在:添加/添加冲突,如果∄ P _乙和P _大号 = P _[R ; 重命名/删除冲突,如果P _B等于左路径或右路径之一,但另一路径不存在; 如果P _B ≠P _L ≠P _R,则重命名/重命名冲突.

如果还没有高级别冲突(添加/添加,重命名/重命名或重命名/删除),则可能仍存在重命名/修改或重命名/删除冲突,只要blob的哈希ID(文件内容) )由两个或三个路径名称命名不匹配.

所有这些"高级别"冲突都会导致合并冲突,但不会导致任何冲突标记.为此,我们现在必须实际将基本文件与两个侧文件合并(这意味着所有三个文件必须存在,或者对于添加/添加案例,我们将一个简单的空文件作为基本版本).

此合并可能有也可能没有自己的冲突.如果合并增加了低级别冲突,我们将获得冲突标记.如果没有高级别冲突(所有三次提交中的路径相同)但需要完全合并(哈希值都不同),我们可能会与冲突标记产生低级别冲突.

Git需要什么来解决文件中的冲突

要在工作树中的一个文件中获得合并冲突,Git必须看到左侧和右侧版本都更改了相同的行,但是以不同的方式进行了更改.(请记住,所有这三个哈希必须有所不同,所以Git是组合一组从变化的,实际上,与那些从.)diff PB PLdiff PB PR

最明显,最不容易混淆的案例

最明显的情况发生在一边(让我们先选择左边)说:

 unchanged context
-changed line
+replacement 1
 more unchanged context

另一个说:

 unchanged context
-changed line
+replacement 2
 more unchanged context

这里删除一行或多行,而是插入一行或多行,但插入的行不匹配.在这种情况下,merge冲突风格表示为:

unchanged context
<<<<<<< left-label
replacement 1
=======
replacement 2
>>>>>>> right-label
more unchanged context

该diff3背景下呈现的风格,而不是这样的:

unchanged context
<<<<<<< left-label
replacement 1
||||||| merged common ancestors
changed line
=======
replacement 2
>>>>>>> right-label
more unchanged context

如果我们只是添加文本,但在同一行添加不同的文本,我们也会遇到合并冲突.同样,来自每一侧的添加文本显示在冲突标记中.(如果我们将相同的文本添加到双方 - 作为新文本,或作为更改行的替换文本,Git将获取此添加的一个副本,并且没有冲突.)

有些令人困惑的案件

如果一个而不是两个的的更换线是空的,也就是说,如果左侧或右侧差异如下:

 unchanged context
-changed line
 more unchanged context

然后一个但不能同时在更换线路merge或diff3风格标记的文件丢失.(如果两个diff只删除原始行,则没有冲突:Git只删除一个.)

同样,如果一方在另一方删除的行的上方或下方添加一行,则会发生冲突.这次冲突表明保留 - 然后添加a的一侧有所有线,而另一侧没有线.例如:

 some merge conflict.
 Line that will conflict.
+add line below it
 Rest of the

VS:

 some merge conflict.
-Line that will conflict.
 Rest of the

(如果添加上面的行而不是下面的行,也会出现相同的情况).

这是diff3冲突风格非常有用的地方.以下是其中一种情况的整个合并文件:

We need a base file
in which to make
some merge conflict.
<<<<<<< HEAD
||||||| merged common ancestors
Line that will conflict.
=======
Change the line that will conflict.
>>>>>>> b2
Rest of the
base file for the
merge conflict example.

请注意,它现在显而易见 - 或者至少不那么神秘 - Line that will conflict.在基本版本中读取了一行,我从左侧HEAD版本中完全删除了该行,并在右侧b2版本中替换为另一行.