Git merge 内部

Question

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

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

W:原始文件，A:爱丽丝的分店，B:鲍勃的分支

根据这个真值表，可以直接想出一个基于行的算法来构造 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()。凭直觉，根据真值表， merge 后的文件似乎最终会删除 foo() 函数并添加 bar() ，Bob 会想知道为什么 foo() 不再起作用了!这可能使我认为我为 3 路 merge 导出的真值表模型可能不完整并且缺少某些东西？

Answer 1

My first question is the case (0, 0, 1)

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

-#define NUMBER_OF_WHATEVER 42
+#define NUMBER_OF_WHATEVER 43

merge 算法无法为您知道您是希望 merge 产生 43(因为这是两个版本都同意的值)还是 44(因为 42 应该递增两次)。

但是，将这种情况视为冲突会导致很多虚假冲突。例如，如果一个人从 master 分支中挑选一个 merge 到一个维护分支，然后将维护分支 merge 到 master 中，那么被挑选修改的每一行都会导致冲突。而且冲突标记会很奇怪，因为它们会在冲突标记的两边显示相同的内容，比如

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

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

My second question is about deletion cases— (0, 1, 1) and (1, 0, 1).

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

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

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

实际上，语义冲突并不是版本控制系统特有的。另一种不使用 merge 的场景是

• 我阅读代码并看到一个函数 f()
• 我的同事删除了函数 f()
• 正在处理不再有 f() 的最新版本，我仍然记得有一个函数 f() 并且我尝试使用它。

简而言之，不要害怕语义冲突。