什么构成 Git 中的合并冲突？答案

【问题标题】：What constitutes a merge conflict in Git?什么构成 Git 中的合并冲突？
【发布时间】：2011-06-22 16:42:01
【问题描述】：

git如何确定特定的合并有冲突以及冲突是什么？

我的猜测是这样的：如果被合并的两个提交有一个共同的父提交，并且如果它们都改变了父提交的 X 行，那就是冲突。

让我的理解更复杂的是：

“更改第 X 行”可能意味着用几行新行替换它，这仍然显示为一个冲突（版本 A 有这一行，版本 B 有这 5 行，或其他）
如果您确实在其中一个提交中插入了行，那么更笨的算法会认为所有后续行已更改：第 30 行现在具有第 25 行的以前的内容，第 31 行具有以前的内容26 等。但是 git 可以看出它们是相同的，我不知道如何。

谁能解释这是如何工作的，或者指向一个链接？

【问题讨论】：

标签： git internals

【解决方案1】：

浏览至此page 上的HOW CONFLICTS ARE PRESENTED 段落。

LE：没有关于冲突案例的真实文档，也没有文件冲突标记，因为我在这里受到了 cmets 的抨击，这里的源代码中的指针接近 git 为了实现而遵循的策略冲突状态。文件merge-recursive.c，搜索"CONFLICT 字符串。通过这样做，我们可以很容易地发现确实存在一些冲突案例，例如：

冲突（重命名/重命名）
冲突（内容）
冲突（重命名/目录）
冲突（重命名/删除）
冲突（重命名/添加）
冲突（删除/修改）
... 以此类推

如果你问我，是的，它们应该被记录并清楚地指出，但它们并不是没有什么可做的，然后检查源代码.. 但是有人真的可以从这里拿起并创建一个很好的文档，然后发送它到 git 项目。

@Wim Coenen 是的，它也取决于合并策略，但是如何呈现冲突提供了更多的见解。如果你问我，你也可以阅读合并策略，但你仍然有疑问。

【讨论】：

您也可以说“RTFM”。我个人觉得git 的文档在这方面有点晦涩。
我不会对此表示反对，因为它是一个有趣的链接，但这并不是我想要的。该段显示了在 git 决定存在冲突之后的样子。我正在尝试了解 git 如何首先确定存在冲突。
相关段落其实是MERGE STRATEGIES
@Wim Coenen - 该段暗示我的问题的答案取决于您选择的合并策略。这很有趣，但就像“嘿，你以为你不明白一件事，这里有十件事你不明白！” :) 也许我们可以解决这个问题的默认策略？

【解决方案2】：

基本上，使用 git，每次合并都是一个冲突，它会留下一个索引，其中包含每个文件的三个版本、来自每个分支的版本和基础版本。在这个索引上，运行了各种解析器，它们可以为每个单独的文件决定如何解决问题。

第一阶段是一个简单的解析器，它负责处理诸如未更改的文件、一个分支修改了一个文件而另一个没有修改的情况，或者两个分支都包含文件的相同新版本的情况。

之后，插件会查看剩余的案例。有一个插件通过识别一个分支中的单个更改（如 diff）并尝试将这些更改应用于另一个分支来处理文本文件，如果这不起作用，则返回放置冲突标记。此时您可以轻松地挂接您自己的合并工具，例如，您可以编写一个知道如何合并 XML 文件而不违反格式良好的工具，或者提供一个允许交互式编辑和并排的图形用户界面- 侧视图（例如，kdiff3 会这样做）。

所以冲突的表现实际上是所使用的插件的问题；文本文件的默认插件将使用与 CVS 相同的样式，因为人们和工具已经习惯了它，并且冲突标记是几乎所有编程语言中的已知语法错误。

【讨论】：

好答案！合并的问题为我阐明了。
"每次合并都是冲突" whaaat?
@mehaase，这就是它的工作原理。 :) 作为用户，很大一部分对您来说是隐藏的（例如琐碎的解析器），但是了解您是否想要自己的解析器很重要。
@DomQ, merge-file 是文本文件的最后合并驱动程序。您可以指定应使用不同的合并驱动程序。
@JanŻankowski，据我所知，这是提交次数。有多个候选提交，其中一个不是另一个的祖先是相当少见的，但是可以选择在这种情况下精确地指定在合并中使用哪个基。基本版本与其前身之间的差异无关紧要。

【解决方案3】：

我认为合并算法与 Git 没有什么特别之处：它是经典的 3-way merge algorithm (not the Codeville one)，可以使用 with several strategies（默认：recurse，或 resolve 或 octopus）。结果是fairly simply merge process，即described here。
然后将任何可视化需求委托给第三方合并/差异工具。

【讨论】：