为什么 3 路合并比 2 路合并更有优势？

Question

维基百科说三向合并比双向合并，通常不需要用户干预。为什么会这样呢？

3 路合并成功而 2 路合并失败的示例会很有帮助。

Answer 1

假设您和您的朋友都签出了一个文件，并对它进行了一些更改。您在开头删除了一行，您的朋友在末尾添加了一行。然后他提交了他的文件，您需要将他的更改合并到您的副本中。

如果您正在进行双向合并（换句话说，差异），该工具可以比较两个文件，并看到第一行和最后一行不同。但它怎么知道如何处理这些差异呢？合并版本应该包含第一行吗？它应该包括最后一行吗？

通过三向合并，它可以比较两个文件，但也可以将每个文件与原始副本进行比较（在您更改文件之前）。因此它可以看到您删除了第一行，并且您的朋友添加了最后一行。它可以使用该信息来生成合并版本。

Answer 2

这张来自 perforce 演示文稿的幻灯片很有趣：

三向合并工具的基本逻辑很简单：

• 比较基础文件、源文件和目标文件
• 识别源文件和目标文件中的“块”：
  • 与基础不匹配的块
  • 与基础匹配的块
• 然后，将合并结果放在一起，其中包括：
  • 所有 3 个文件中彼此匹配的块
  • 与源或目标中的基础不匹配但两者都不匹配的块
  • 与基础不匹配但彼此匹配的块（即，它们在源和目标中都以相同的方式进行了更改）
  • 冲突块的占位符，由用户解决。

请注意，此图中的“块”纯粹是象征性的。每个都可以代表文件中的行、层次结构中的节点、甚至目录中的文件。这完全取决于特定合并工具的功能。

您可能会问 3 路合并比 2 路合并有什么优势。实际上，不存在双向合并这样的东西，只有能够区分两个文件并允许您通过从一个文件或另一个文件中选取块来“合并”的工具。
只有三向合并才能让您知道某个块是否是对源的更改以及更改是否冲突。

Answer 3

三向合并是指将两个变更集在应用时合并到一个基本文件，而不是应用一个变更集，然后将结果与另一个合并。

例如，在同一位置添加一行的两次更改可能会被解释为两次添加，而不是一行的更改。

例如，文件a已被两个人修改，其中一个添加了moose，另一个添加了mouse。

#File a
    dog
    cat

#diff b, a
    dog
+++ mouse
    cat

#diff c, a
    dog
+++ moose
    cat

现在，如果我们在应用变更集时合并它们，我们将得到（三向合并）

#diff b and c, a
    dog
+++ mouse
+++ moose
    cat

但是如果我们应用 b，然后查看从 b 到 c 的更改，看起来我们只是将“u”更改为'o'（2 路合并）

    #diff b, c
    dog
--- mouse
+++ moose
    cat

Answer 4

在日常工作中，只要有可能，我们都会做或者更愿意让 git 做双向合并。问题是为什么需要3 路合并，而不是默认的2 路合并。

默认的合并策略是快进合并（见下左图），但是如果git无法进行快进合并因为开发历史已经出现分歧，示例额外提交已提交到源分支（但不是由您提交），git 必须做一些工作，并且它使用三向合并< /code>（下右图）​​。可以在此处找到推荐阅读内容。当然，对于 git 的所有内容，您还可以通过使用选项 --no-ff 来决定进行 3 向合并，即使不需要。

借自 AWS CodeCommit：
开发者工具>代码提交>存储库>存储库名称>
拉取请求>拉取请求名称>合并