邪恶在git中合并？答案

【问题标题】：Evil merges in git?邪恶在git中合并？
【发布时间】：2010-11-30 12:29:04
【问题描述】：

“man gitglossary”包含邪恶合并的定义：

邪恶的合并是引入了没有出现的更改的合并在任何父母中。

我不确定我是否理解作者试图表达的观点。为什么是邪恶的？

【问题讨论】：

我从this page 来到这里，发现它不是git's evil merge 非常有帮助：邪恶合并不是一些自然现象，有时会发生;相反，这是人们有时会在 git 中做的事情（就像人们有时会导致其他事故，例如将 --forced 更改为公共 repo）。这里的要点是：不要那样做！（或至少保留合并语义）
说得对，这是 Linus Torvalds 自己的话：“邪恶合并”是指做出来自任何一方的更改，实际上并没有解决冲突
请注意，如果您重复合并（就像您将使用的，例如，Git 2.18 的新--rebase-merges 功能），您在进行合并时采取的特殊操作邪恶合并——或其他人在他们进行时采取的特殊行动——不会自动重复，合并结果会有所不同。换句话说，合并将失去其“邪恶”。这可能是称其为“邪恶”的另一个原因，特别是如果结果是好的/重要的。

标签： git merge

【解决方案1】：

因为它在代码中加入了从来没有人要求出现的东西。好像你有这个代码：

$foo = bar;
$baz = qxx;

还有这个变化：

$foo = bar;
$foo++;
$baz = qxx;

与此更改合并：

$foo = bar;
$foo--;
$baz = qxx;

以某种方式产生：

$foo = bar;
$foo++;
$foo--;
--$baz;
$baz = qxx;

显然，这是邪恶的。

我猜想在man gitglossary 中已经引起了足够的关注，因为你的合并算法涉及的越多，它们就越有可能产生这样的东西。

【讨论】：

要生成这个，只需使用 --no-commit 选项调用 git-merge，添加更多更改，签入并提交。将自动使用预先生成的合并提交消息。
@Jefromi 根据这个定义，任何必须手动解决的冲突合并都是邪恶的合并？ @chaos 所说的语义有很大差异；您可能会得到他的结果，而不会在合并过程中遇到任何冲突。这是真正的邪恶。
--$baz;来自。我不认为 GIT 随机生成代码。对我来说，在没有任何人澄清哪个是正确代码的情况下合并增量和减量已经够邪恶了。结果是这两个更改破坏了代码。不知从何而来的行必须由某人手动“纠正”合并。到那时，这不是 GIT 的错？！？！？
我明白了。邪恶合并是引入不是由程序员编写的代码的合并过程。再一次，我认为如果没有人给予足够的关注，合并可以产生一个增量，然后是一个减量，这已经足够邪恶了。合并使这两个版本毫无意义。
@Xaade: git 本身不会产生该结果。它将产生一个带有冲突标记的版本（即：<<<<<< HEAD\n [code from head]\n ======\n [code from branch]\n >>>>>> branch，它不会提交。然后由程序员手动解决冲突。如果他们这样做而不引入新代码，那么它不是邪恶的。所以Chaos 的最后一个例子不是没有--$baz; 行的邪恶合并。那将是一个愚蠢的合并，但错误在于程序员，而不是git。

【解决方案2】：

用 Linus Torvalds 自己的话（取自git mailing list）：

一个“邪恶的合并”是一种既不来自任何一方的改变并没有真正解决冲突

【讨论】：

【解决方案3】：

我认为它可能被命名为“邪恶合并”，因为在注释文件（生成逐行历史注释）时，“git blame”很难解决极端情况。

当您在主分支上开发功能“A”和在侧分支上开发功能“B”时，可能需要进行邪恶合并，并且这些功能在语义（非文本）方式上发生冲突。一个例子是对全局变量使用相同的名称，但具有不同的含义——这需要为其中一个特性重命名变量。

对于邪恶合并“git show --cc”具有非空紧凑组合差异（但我不确定它是否是等价关系；暗示可能仅在一个方向上，即“邪恶合并”然后非空“@ 987654322@")。

【讨论】：

直觉上，@chaos 的反应感觉更正确，但我知道你很擅长这些事情 ;) 感觉就像你在描述一个很好的旧合并冲突，其中 2 人已经解决了重叠同一个问题的一部分——甚至可能是同一个问题。合并完成后，为什么要重新创建它？把这个“相当常规”的事件称为“邪恶”是不是太诗意了？
解决冲突通常涉及选择一个版本而不是另一个版本，有时选择一个版本行而不是其他版本的行。邪恶合并的行不在其任何父级中，因此即使通过最复杂（通用）的合并策略也无法自动重新创建它。
（删除了关于“邪恶”合并和自动化过程的行）
我认为您正确地强调了“通常”。有时，minimal 手动解析会导致不存在的行。（例如，'ours' 更改了函数的名称，'theirs' 更改了返回值，我们需要一个具有新名称的方法和新的返回值）。这是邪恶的吗？ IOW：邪恶的合并有时是必要的吗？ +1

【解决方案4】：

值得一提的是，“邪恶合并”中的“邪恶变化”可能会静默丢失，同时重新定位包含与其他不冲突的“邪恶变化”的“邪恶合并”提交。使用--preserve-merges 对such a case 没有帮助。

【讨论】：