邪恶在吉特融合-他们从哪里来?

它在正确的第一个注释中解释 answer . 合并时不进行提交(通过冲突或--不提交),然后在提交前向合并添加其他更改。

注意,解决合并冲突并不是坏事,您只需选择冲突一方或双方存在的代码。如果你添加了一些不存在于任何一方的代码,你现在已经变成了合并的恶魔。

That comment 是一个有趣的例子,说明了“邪恶”合并是如何发生的:

有时,最小的手动分辨率会导致不存在的行。
如。

• ’ ours '更改函数的名称,
• ’ theirs '更改返回值,
• 我们需要一个具有新名称和新返回值的方法)。

这是邪恶的吗?罪恶的合并有时是必要的吗?

注意 this article 在另一个上下文中提到“邪恶合并”(未经理解的合并),并主张总是重新平衡,而不是合并…但那 would ignore the danger of a git pull --rebase .

Junio C Hamano,Git的主要维护人员,他的 April 2013 blog post :

在现实生活中发生“邪恶合并”的一个典型例子是调整语义冲突。它几乎与文本冲突无关。

(通常是API更改,例如:您添加一个参数,而另一个开发人员添加对该函数的调用…但是 没有 任何额外参数)

这意味着您必须在合并时修复语义冲突(就像现在接受的函数缺少参数一样),这意味着创建一行:

• 代码中不存在(您在其中正确地进行了API更改)
• 您正在合并的远程分支中不存在(其他开发人员不知道API更改的地方)

这使得合并成为“邪恶的合并” .

用“ git log -c/--cc “ 这样的一行将显示双加 在多路补丁输出中显示 这两个父级中都不存在 “。

从 git log man page :

差异格式

-c::

使用此选项,合并提交的diff输出将同时显示每个父级与合并结果之间的差异,而不是一次显示父级与结果之间的成对差异。
此外,它只列出从所有父级修改的文件。

当开发人员遇到必须手动修复的合并冲突时,就会发生这种情况,并且在执行此操作时,他会更改与合并冲突本身无关的代码。Git的合并算法不会自行插入无关的“邪恶”代码更改。