为什么 git 在挑选樱桃时会发生冲突？

Question

我使用 git 已经有一段时间了，但我从来没有真正理解为什么会发生合并冲突。 我学会了快速解决它们，但我觉得不理解它们为什么会发生让我不开心。 最常见的解释是the same code region was changed by 2 different commits and now git cannot decide which one to pick仅对最简单的情况有意义。

为了更好地理解发生了什么，我创建了一个包含 2 行的简单文件：

a
b

并提交它（日志消息初始化，分支主）。

然后我从master创建了一个feat分支并添加了第三行： c

然后我从master创建了另一个feat2分支并将b更改为bb 。

最后，我将master中的第一行更改为ax 。

生成的树如下所示：

$ git tree
* f4c4a9d (feat) add 3rd line: c
| * f050bf8 (feat2) changed 2nd line: b -> bb
|/  
| * 244ed21 (HEAD -> master) change 1st line: a -> ax
|/  
* 51fca0f init

如果我想挑选或合并feat到大师，它工作正常，但如果我想挑选改变第二行的feat2 ，它会失败并且无法弄清楚为什么会发生这种情况。

Answer 1

为了让 git 能够应用更改，git 需要能够获得受影响部分之间的共同边界。 如果合并过程中不存在公共线（请记住，cherry-pick 就像普通合并，唯一的技巧是在普通合并中被视为共同祖先，在cherry-pick 中它是被迫成为您正在挑选的修订版的父级），那么 git 只会向您显示一个冲突块。

请记住，您考虑的不是文件的 2 个版本，而是三个.

一个版本是共同祖先（在您的情况下，它确实是共同祖先，但在通常情况下并非如此）：

a
b

大师的提示：

ax
b

壮举2：

a
bb

如果您考虑在 3 个版本之间没有变化的情况，那么没有任何东西可以幸存下来...... git 无法弄清楚应该发生什么。 你会发生冲突。 如果 a 和 b 之间只有一条不变的线，就没有问题。 在 a 和 b 上尝试相同的更改，但从第一个修订版的此文件开始：

a
x
b

那么git采樱桃就没有问题了。 如果您尝试使用设置为diff3的merge.conflictStyle进行合并，这可能更有意义，这样您就可以看到代码在所涉及的 3 个版本中的情况。

旁注：如果您不介意坐下来阅读，您可能想看看我在这个主题上写的东西（没有货币化，没有跟踪）： http://www.ezconflict.com

Answer 2

最常见的解释是相同的代码区域被 2 个不同的提交更改，现在 git 无法决定选择哪个仅对最简单的情况有意义。

嗯，不……这就是解释，它适用于所有情况。 您可能遗漏的细节是，如果受“我们的”更改影响的行和受“他们的”更改影响的行之间没有至少一条不受影响的行，则这些更改被认为是重叠的。

所以在你的例子中：

在master你改变了第一行。

在其中一个分支中添加了第 3 行； 由于第 2 行在它们之间，因此这不是冲突。

但是在另一个分支中，您更改了第 2 行。第 1 行和第 2 行之间没有行，所以这会与 master 上的更改冲突； 此外，它会与在另一个分支中添加第 3 行冲突（因为第 2 行和第 3 行之间没有行）。