我已经阅读了这个问题和答案,但对我来说不清楚的是谁创建了“在任何父级中都没有出现的更改”。
是git合并算法搞砸了吗?
还是因为用户必须手动调整冲突以使其构建,引入了在任何一个父级中都不存在的新代码?
这在正确的答案的第一条评论中有解释。你合并时没有进行提交(通过冲突或--no-commit),然后在提交之前添加了额外的更改。
注意,解决合并冲突并不是邪恶的,你只需选择存在于一个或两个冲突方的代码即可。如果你添加了某些不存在于任何一方的代码,现在就变成了邪恶的合并。
那个评论是一个有趣的例子,说明了"恶意"合并是如何发生的:
有时候最小的手动解决方案会导致出现之前不存在的代码行。
例如:
- '
ours
' 改变了函数名称,- '
theirs
' 改变了返回值,- 我们需要一个新名称和新返回值的方法。
这算是一个恶意合并吗?也就是说,恶意合并有时是必要的吗?
请注意,这篇文章在另一个上下文中提到了"恶意合并"(不期望的合并),并主张始终使用变基(rebase)而不是合并...但这会忽略"git pull --rebase"的危险。
这使得合并成为了"恶意合并"。
使用"
git log -c/--cc
",这样一行将会以双加号的形式出现在多向补丁输出中,以显示"它在父提交中不存在"。
来自git log
手册页面:
-c::
当开发人员遇到合并冲突时,他必须手动解决,而在这样做的过程中,他会更改与合并冲突本身无关的代码。Git的合并算法不会自行插入不相关的“恶意”代码更改。
git log -c
显示带有 '++' 的行。请参见我下面编辑过的答案。 - VonCgit://devil@github.com/hell.git
添加为远程仓库并拉取了代码... 在此过程中遇到了许多恶意合并。我不建议这样做。 - ereOn