git - 什么是二向和三向差异/merge ？

Question

1 <- 2 <- 5 (merge commit) <- master <- HEAD
 \       /
  3 <-- 4 <- dev

1. 双向 merge 是否仅在 merge 期间使用提交 2 和 4？如果我是对的，那么在哪些情况下使用双向 merge ？
2. 什么是双向差异？
3. 什么是三向差异？

Answer 1

我认为没有人真正谈论“双向差异”；他们只是“差异”。在实践中，我也没有看到使用“三向差异”这个短语，但在版本控制中，它是一对差异的明显标签，从一个共同的 merge 基础开始，查看两个后续但不同的快照。 (您也可以查找“interdiff”。参见 How do I get the interdiff between these two git commits? 和 https://linux.die.net/man/1/interdiff。)

术语 merge 有多重含义，并且在谈论 K-way merge sort 时(例如，与 Git 无关)定义明确。但是，当涉及到版本控制(比 Git 更通用)时，短语三向 merge 非常具体，指的是从 merge 基础 开始的 merge 版本，其中有两个分歧。

利用版本控制系统定义“三向 merge ”的事实，有些人制作了一种 back-formation 来将应用单个差异的过程称为“双向 merge ”。在我看来，这不是一个好词，因为没有真正的 merge 在进行。只需将其称为“应用差异”或“应用补丁”即可。

另见 Why is a 3-way merge advantageous over a 2-way merge? 请注意，谈论 4 路甚至 5 路 merge 的评论并不真正适用于 Git。

您可以使用 git diff --full-index <commit1> <commit2> | git apply -3 让 Git 对单个文件进行三向 merge ，其中每个文件的每个 merge 基础版本都是从 index 行中单独选择的。但是，这与选择与 <commit1> 关联的所有文件作为 merge 基础在本质上是相同的。其工作方式是 git diff 在其输出中打印每个 blob 的哈希 ID，如果 git apply 无法按原样应用补丁，Git 将使用打印的 blob ID 定位原始文件，然后计算第二个差异将基本版本 merge 到文件的当前版本。¹ 然后将两个差异提供给 merge 机制。 (另请参见 the git merge-file command。)但请注意， <commit1> 中每个文件的 blob 哈希严格由附加到 <commit1> 的树对象确定。因此，这与说 the files associated with <commit1> 没有什么不同。也就是说，除了一个异常(exception)没有什么不同:如果 Git 有提交哈希 ID，或者对应的树 ID，Git 可以做一个树范围的文件比较来寻找重命名操作，之后 Git 可以关联 merge 库的文件路径 < em>P_B 具有不同 路径 P_L，“本地”或 --ours 文件.

换句话说，git diff --full-index <parent> <child> | git apply -3 和 git cherry-pick <child> 之间的主要区别在于，前者在回退“三向补丁”操作期间不会检测重命名，甚至不会尝试对任何一个文件进行三向 merge ，如果它能够在没有它的情况下进行补丁应用。我认为，很难(但并非不可能)构建产生截然不同结果的人工示例，但我现在没有时间这样做。

---

¹这里的事情变得有点复杂，因为“当前版本”不一定是 HEAD 版本。具体来说，git apply 使用工作树版本作为 --ours 变体，而 git apply --index 使用索引版本作为 --ours 变体。然而，git cherry-pick 命令要求索引和工作树默认是“干净的”，即匹配 HEAD 提交。在这种情况下，“HEAD 版本”、“索引版本”和“工作树版本”之间通常没有区别。