26

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

Git 是否有独立于您设置的合并工具/差异工具的内部冲突检测/合并工具？

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

我的情况很奇怪，Git 显示它无法自动合并，但图形工具显示没有问题。

4

4 回答 4

15

Git 有一个独立于difftool. 无论如何，您可以从手册中指定merge strategy使用该-s选项：

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

使用给定的合并策略；可以多次提供以按应尝试的顺序指定它们。如果没有 -s 选项，则使用内置的策略列表（合并单个头时使用 git merge-recursive，否则使用 git merge-octopus）。

策略从简单FastForward到Octopus合并大量树时。检查此答案以了解不同merge策略的工作原理。

无论如何，您的情况很奇怪。也许您的 IDE 正在使用不同的合并策略，因此当它打开时，它会以正确的方式进行合并。

于 2013-07-15T14:39:16.500 回答
13

正如Atropo 在他的回答中所说，

Git 有一个独立于difftool.

因此，Git 会自行决定更改何时导致冲突，而不是通过使用您正在使用的任何外部差异或合并工具（可能使用它们自己的冲突检测和解决策略）。

根据VonC对什么构成 Git 中的合并冲突的回答？（强调我的）：

我不认为合并算法与 Git 有什么特别之处：它是一种经典的3 路合并算法（不是 Codeville合并算法），它可以与多种策略一起使用（默认：递归、解析或章鱼）。结果是这里描述的相当简单的合并过程。 然后将任何可视化需求委托给第三方合并/差异工具。

他链接到的维基百科文章因此解释了三向合并（强调我的）：

在文件“A”和文件“B”之间的自动差异分析之后执行三向合并，同时还考虑两个文件的起源或共同祖先。这是一种粗略的合并方法，但真正适用于广泛，因为它只需要一个共同的祖先来重建要合并的更改。

三向合并使用已更改文件的祖先来标识在任何一个、一个或两个派生版本中都未更改的内容块。两者都没有改变的块保持原样。仅在一种衍生产品中发生更改的块使用更改的版本。如果一个块在两个派生中都发生了变化，如果两边的内容相同，则使用更改后的版本，但如果更改不同，则将其标记为冲突情况，留给用户解决。

三路合并由无处不在的diff3程序实现，是允许从基于文件锁定的修订控制系统切换到基于合并的修订控制系统的核心创新。它被并发版本系统(CVS) 广泛使用。

这篇文章还谈到了递归三向合并，我看到它在 Git 中经常使用：

基于三向合并的修订控制工具的广泛使用带来了一些案例，其中头脑简单的三向合并会导致虚假冲突，有时会默默地重新制定恢复的更改。这种情况的示例包括交叉合并和三向重命名冲突。

三路合并的问题出现在两个派生状态没有唯一的最新共同祖先 (LCA) 的情况下。为了解决这些问题，递归三路合并通过首先合并非唯一祖先来构造一个虚拟祖先。Git修订控制工具使用此技术。

递归三向合并只能在工具了解要合并的导数的总祖先 DAG（有向无环图）的情况下使用。因此，它不能用于衍生或合并未完全指定其父级的情况。

于 2013-07-27T17:33:59.690 回答
2

是的，许多 IDE 和合并工具会在 git 自身的基础上自动解决冲突。

如 中所见git help merge-file，git 的文本文件库存冲突解决算法相当简单：diff 块冲突如果它们改变相邻行。如果 git 无法以这种方式自动解决冲突，它将以自 RCS 时代以来一直是标准的格式放置一个文本冲突标记，并且 IDE 可以接受并继续工作（即使它没有了解git）：

<<<<<<<< 版本标识符 1
富
=======
酒吧
>>>>>>>> 版本标识符 2

我不使用 Visual Studio，但快速的 Google 告诉我它具有自动冲突解决功能。（我自己用的是kdiff3，有自己的自动冲突解决算法）

于 2013-07-26T10:43:38.067 回答
1

这里的帖子是我在 git 合并策略上看到的最好的答案。是的，你可以选择你想要的-s option

但是您的问题是，为什么其他工具（例如 Visual Studio）在 git 不能合并时会合并它。Visual Studio 可以有一个相当激进的合并策略——“自动合并功能通常不会使用旧版本中的任何内容，因为自动合并功能的默认设置有利于最新文件”，请参阅此处了解更多信息。

要了解有关 VS 2012 附带的合并工具的更多信息，请参阅此帖子，其中 Brian Harry 深入探讨了他们如何将“合并时的最小冲突”视为一项关键功能。

至于 Perforce，我怀疑他们有类似的合并策略 - git 到 p4 的连接器必须使用 perforce 合并策略来弄清楚，我相信他们也更具侵略性。

“我们的”可能是 git 中类似的激进合并策略。

但总而言之，每个产品都使用自己的合并策略，有些或多或少具有侵略性。这取决于您的用例和可接受的需求。

于 2013-07-26T22:57:30.197 回答