Git合并内部

Question

这可能最终会成为一个很长的问题，所以请多多包涵。

我在这里遇到了一个关于 git 合并决策的令人难以置信的解释：How does git merge work。我试图建立在这个解释的基础上，看看以这种方式描述 git merge 是否有任何漏洞。本质上，合并文件中是否出现一行的决定可以用真值表来描述：

W：原始文件， A：爱丽丝的分支， B: Bob 的分支

基于这个真值表，很容易想出一个基于行的算法来构造 D：通过查看 A 和 B 中相应的行并根据真值表做出决定，逐行构造 D。

我的第一个问题是 case (0, 0, 1)，根据我上面发布的链接，这似乎表明虽然这种情况实际上是一个冲突，但 git 通常通过删除该行来处理它。这个案子真的会导致冲突吗？

我的第二个问题是关于删除案例 - (0, 1, 1) 和 (1, 0, 1)。直觉上，我觉得这些案件的处理方式可能会导致问题。假设 W 中有一个函数 foo()。这个函数实际上从未在任何代码段中调用过。假设在分支 A，Alice 最终决定删除 foo()。然而，在分支 B，Bob 最终决定使用 foo()，并编写了另一个名为 foo() 的函数 bar()。直观地说，根据真值表，似乎合并后的文件最终会删除 foo() 函数并添加 bar()，而 Bob 会想知道为什么 foo() 不再起作用了！这可能让我认为我为 3 路合并导出的真值表模型可能不完整并且遗漏了什么？

Answer 1

我的第一个问题是 (0, 0, 1)

某些版本控制系统（例如 darcs）认为，在两个分支中进行相同的更改（在您的情况下是删除）并将它们合并会导致冲突。典型的例子是当你有两次时

-#define NUMBER_OF_WHATEVER 42
+#define NUMBER_OF_WHATEVER 43

合并算法无法知道您是希望合并产生 43（因为这是两个版本都同意的值）还是 44（因为 42 应该增加两次）。

但是，将此案例视为冲突会导致许多虚假冲突。例如，如果一个cherry-pick从master分支合并到一个维护分支，然后将维护分支合并到master，那么cherry-pick修改的每一行都会导致冲突。而且冲突标记会很奇怪，因为它们会在冲突标记的两侧显示相同的内容，比如

<<<<<<< HEAD
Hello world
=======
Hello world
>>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086

因此，包括 Git 在内的大多数版本控制系统都选择在合并双方引入相同更改时不考虑冲突。

我的第二个问题是关于删除案例——(0, 1, 1) 和 (1, 0, 1)。

您所描述的是语义冲突。它们在理论上确实存在，您甚至可以找到合并可编译但与正在合并的分支相比具有不同语义的极端情况。没有魔法，没有文本合并算法可以检测或解决语义冲突。你必须和他们一起生活，或者独自工作。

在实践中，它们非常罕见。每天可能有数百万人使用版本控制系统并与之共存。大多数人可能从未想过问题会存在。

不过，一个好的组织可以大大降低语义冲突的风险。如果你检查你的代码在合并后仍然可以编译，你可以避免大约 90% 的语义冲突，如果你有一个自动测试套件，那么你必须找到一个语义冲突，它会创建一个你的测试套件没有涵盖的错误。有问题。

实际上，语义冲突并非特定于版本控制系统。另一个不使用合并的场景是

• 我读了代码，看到了一个函数f()
• 我的同事删除了函数f()
• 正在做最新的版本，已经没有f()了，我还记得有一个函数f()，我尝试使用它。

总之，不要害怕语义冲突。

Answer 2

这里有一个sample repository 供您自己测试不同的合并行为。它有很多分支，可以相互合并。

随意分叉或克隆它：

git clone https://github.com/NickVolynkin/GitMergeResearch.git

我会尽快发布我的结果。