Git如何决定冲突？

Question

当我从团队中的其他人修改某个文件时从GitHub撤出时,Git命令显示存在Git无法解决的未解决冲突.我打开Perforce或Visual Studio 2012来修复冲突,图形工具显示我没有冲突并快速执行合并.

Git是否有一个独立于你的set mergetool/difftool的内部冲突检测/合并工具？

或者它是否使用您配置的工具自动合并并检测无法解决的冲突？

我的场景很奇怪,Git表明它无法自动注册,但图形工具没有显示任何问题.

Answer 1

Git有一个独立的内部合并系统difftool.无论如何,您可以从手册中指定merge strategy使用-s选项:

-s <strategy>
--strategy=<strategy>

使用给定的合并策略; 可以多次提供,以按照应该尝试的顺序指定它们.如果没有-s选项,则使用内置的策略列表(合并单个头时git merge-recursive,否则使用git merge-octopus).

策略从简单FastForward到Octopus合并大量树木.选中此asnwer看到不同的是如何merge战略工作.

无论如何你的场景很奇怪.也许您的IDE正在使用不同的合并策略,因此当它打开时,它会以正确的方式合并.

Answer 2

正如Atropo在他的回答中所述,

Git有一个独立的内部合并系统difftool.

因此,Git决定何时更改会导致冲突,而不是使用您正在使用的任何外部差异或合并工具(可能使用自己的冲突检测和解决策略).

据VonC的回答到什么构成Git中合并冲突？(强调我的):

我不认为合并算法与Git有任何特殊之处:它是一种经典的3向合并算法(不是Codeville 算法),它可以与几种策略一起使用(默认:递归,或解析或章鱼).结果是一个相当简单的合并过程,这里描述.
然后将任何可视化需求委托给第三方合并/差异工具.

他链接到的维基百科文章解释了3向融合(强调我的):

在文件"A"和文件"B"之间的自动差异分析之后执行三向合并,同时还考虑两个文件的原点或共同祖先.这是一种粗略的合并方法,但实际上可以广泛应用,因为它只需要一个共同的祖先来重建要合并的变化.

三向合并使用已更改文件的祖先来标识在派生版本中的一个或两个中都未更改的内容块.两者中已更改的块都保持不变.仅在一个衍生版本中更改的块使用了更改版本.如果两个导​​数中的块都已更改,则如果两侧具有相同的内容,则使用更改的版本,但如果更改不同,则将其标记为冲突情况并留给用户解析.

三向合并是由无处不在的diff3程序实现的,并且是允许从基于文件锁定的修订控制系统切换到基于合并的修订控制系统的核心创新.它由Concurrent Versions System(CVS)广泛使用.

文章还讨论了递归三向合并,我在Git中看到了很多:

广泛使用基于三向合并的修订控制工具已经提出了这样一种情况:简单的三向合并会导致虚假的冲突,有时会默默地重新制定恢复的变化.此类情况的示例包括纵横交错合并和三向重命名冲突.

在两个导数状态不具有唯一的最新共同祖先(LCA)的情况下出现三向合并的问题.为了解决这些问题,递归三向合并首先通过合并非唯一祖先来构造虚拟祖先.Git版本控制工具使用此技术.

递归三向合并仅可用于工具知道要合并的导数的总祖先DAG(有向非循环图)的情况.因此,它不能用于衍生工具或合并未完全指定其父母的情况.