为什么3路合并优于2路合并？
维基百科表示，3路合并比2路合并更容易出错，而且往往不需要用户干预。 这是为什么？
一个3路合并成功和2路合并失败的例子会很有帮助。
说你和你的朋友都签出了一个文件，并对其进行了一些修改。 你在开始时删除了一行，而你的朋友在最后添加了一行。 然后他做了他的文件，你需要将他的修改合并到你的副本中。
如果您正在进行双向合并（换句话说，diff），则该工具可以比较两个文件，并看到第一行和最后一行是不同的。 但是，它将如何知道如何处理这些差异呢？ 合并版本应该包含第一行吗？ 应该包括最后一行吗？
使用三向合并，它可以比较两个文件，但也可以将它们与原始副本进行比较（在您更改之前）。 所以它可以看到你删除了第一行，并且你的朋友添加了最后一行。 它可以使用该信息来生成合并版本。
演示文稿中的这张幻灯片很有意思：
三向合并工具的基本逻辑很简单：
- 比较基本，源和目标文件
- 识别源文件和目标文件中的“块”：
- 不符合基数的块
- 符合基地的块
- 然后，把一个合并的结果放在一起组成：
- 在所有3个文件中相互匹配的块
- 在源代码或目标代码中不匹配基本块的块，但在两者中都不匹配
- 不匹配基础但是相互匹配的块（即，在源和目标中它们已经以相同的方式改变）
- 冲突的块的占位符由用户解决。
请注意，这个插图中的“块”是纯粹的符号。 每个可以代表文件中的行，或层次结构中的节点，甚至可以代表目录中的文件。 这一切都取决于一个特定的合并工具是能够的。
您可能会问，双向合并在双向合并上提供了多大的优势。 实际上，没有这样的双向合并的东西，只有两个文件不同的工具，可以通过从一个文件或另一个文件中select块来“合并”。
只有三路合并才能让您知道块是否是从原点发生的变化以及是否发生变化冲突。
我写了一篇非常详细的文章 。 基本上，你不能跟踪删除/添加双向，非常非生产性。
三种合并方式，将两个变更集合合并为一个基本文件，而不是应用一个基本文件，然后将结果与另一个合并。
例如，在同一地点添加一行的两个改变可以被解释为两个增加，而不是一行的改变。
例如
文件一个被两个人修改了，一个加了驼鹿，一个加了个鼠标。
#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”（双向合并）
#diff b, c dog --- mouse +++ moose cat
