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

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

正常三向合并所需的元素

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

>合并基础提交B,1

>当前提交L(左侧,又名HEAD),其中B为祖先,

>另一个提交R,也有B作为祖先.

由于“is ancestor”允许提交图中的节点相等(技术上它是先前或相等的≼比较),因此可能有B = L和/或B = R.但是,如果是这种情况,那么就没有合并是必需的,如果你强制合并(使用git merge –no-ff-这意味着B = L和L≺R;两个非强制情况是“快进”而不是实际合并和“没有合并“错误”将没有合并冲突.因此我们可以假设合并基础在合并的两侧之前.

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

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

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

>如果路径P存在于B,L和R的所有三个中,则具有路径P的三个文件被一起识别. (也就是说,有一个路径PB,比如path / to / foo.txt,它有一个匹配的PL路径/到/ foo.txt和PR路径/到/ foo.txt.显然这个文件是“同一个文件”在整个合并期间,所以Git将三条路径标识为一个文件.)

>或者,最多可能有三个不同的路径,PB path / to / basename,PL path2 / to2 / left,以及PR path3 / to3 /