Git合并内部

Question

这可能最终会成为一个很长的问题，所以请耐心等待。

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

W：原始文件，A：Alice 的分支，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 应该增加两次）。

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

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

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

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

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

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

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

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

• 我阅读了代码并看到了一个函数 f()
• 我的同事删除功能 f()
• 在最新版本上工作，现在已经没有f()了，我仍然记得有一个功能f()，我尝试使用它。

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