Wikipedia 说,3路合并比2路合并更不容易出错,而且通常不需要用户干预。为什么会这样?
举一个3路合并成功,2路合并失败的例子会很有帮助。
三向合并是指在应用一个基本文件的两个更改集时合并它们,而不是应用一个更改集,然后将结果与另一个合并。
例如,在同一位置添加一行的两次更改可以解释为两次添加,而不是更改一行。
例如,文件a已经被两个人修改了,一个人添加了moose,一个人添加了mouse。
a
moose
mouse
#File a dog cat #diff b, a dog +++ mouse cat #diff c, a dog +++ moose cat
现在,如果我们在应用变更集时合并它们,我们将得到(3-way merge)
#diff b and c, a dog +++ mouse +++ moose cat
但如果我们应用b,然后看看从b到c的变化看起来就像我们把一个u变成了一个o(双向归并)
#diff b, c dog --- mouse +++ moose cat
假设您和您的朋友都签出了一个文件,并对其进行了一些更改。你在开头删除了一行,而你的朋友在末尾添加了一行。然后他提交了他的文件,您需要将他的更改合并到您的副本中。
如果您正在进行双向合并(换句话说,diff),该工具可以比较两个文件,并查看第一行和最后一行是否不同。但它怎么知道如何处理这些差异呢?合并后的版本应该包括第一行吗?应该包括最后一行吗?
使用三向合并,它可以比较这两个文件,但也可以将它们与原始副本(在任何一方更改它之前)进行比较。所以它可以看到你删除了第一行,而你的朋友添加了最后一行。它可以使用这些信息生成合并后的版本。
这张幻灯片来自一个强制表示是有趣的:
三路合并工具的基本逻辑很简单: 比较基本文件、源文件和目标文件 识别源文件和目标文件中的“chunk”文件: 与基础不匹配的块 与基相匹配的块 李< / ul > < / > 然后,将合并的结果放在一起,包括: 三个文件中彼此匹配的块 源数据和目标数据中与基不匹配但两者都不匹配的数据块 不匹配基础但相互匹配的数据块(即,它们在源和目标中以相同的方式被更改) 冲突块的占位符,由用户解析。 李< / ul > < / > 注意,图中的“块”纯粹是象征性的。每个都可以表示文件中的行,或层次结构中的节点,甚至是目录中的文件。这完全取决于特定合并工具的功能。 你可能会问3路合并比2路合并有什么优势。实际上,没有双向合并这样的东西,只有区分两个文件的工具,并允许您通过从一个文件或另一个文件中选择块来“合并” 只有3-way的合并才能让你知道一个块是否是对原点的更改,以及更改是否冲突
三路合并工具的基本逻辑很简单:
注意,图中的“块”纯粹是象征性的。每个都可以表示文件中的行,或层次结构中的节点,甚至是目录中的文件。这完全取决于特定合并工具的功能。
借用AWS CodeCommit: 开发工具>CodeCommit祝辞库比;RepositoryName祝辞 拉请求>拉请求名称>合并< / em > < / p >