为啥在这种特殊情况下 git revert 后我会发生冲突

Posted 2023-02-21

【中文标题】为啥在这种特殊情况下 git revert 后我会发生冲突

【英文标题】：Why do I get conflicts after a git revert in this special case为什么在这种特殊情况下 git revert 后我会发生冲突

【发布时间】：2018-07-28 02:10:38

【问题描述】：

我有一个文件，一开始看起来像这样

asd
bnm
cvb

然后我添加了三个提交：

1.

asd feature1 c1
bnm
cvb

2.

asd feature1 c1
bnm feature1 c2
cvb

3.

asd feature1 c1
bnm feature1 c2
cvb feature1 c3

现在，当我想通过执行

来恢复第二次提交时

git revert HEAD^

我收到这样的错误消息

error: could not revert 2222222... feature 1 commit 2
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

我的文件看起来像这样

<<<<<<< HEAD
bnm feature1 c2
cvb feature1 c3
=======
bnm
cvb
\>>>>>>> parent of 2222222... feature 1 commit 2

我就是不明白为什么。我的假设是它会像 Edwar Thomson 在他对这个问题的回答中解释的那样工作： git revert: Why do I get conflicts? 我没有两次编辑第 2 行，不应该发生冲突。我错过了什么？

我希望结果是

asd feature1 c1
bnm
cvb feature1 c3

没有任何冲突。

【参考方案1】：

这里缺少的是，一个恢复，就像一个樱桃挑选，只是应用一个补丁（这里是过去提交的负面形象）。 它没有合并。

这意味着，正如我在“Git cherry-pick causes merge conflict while merging does not”中所描述的，它没有共同祖先的概念。

问题是由 git revert 计算的补丁的上下文：请参阅“Conflicts from apply and stash”。

还原（2 和 1 之间的负差异）尝试取消具有 not cvb 作为第三行。 应用该补丁时，Git 不知道如何处理第三行：应该不理会它，还是将其修改为 cvb。

参见“Why does this cherry-pick have a conflict?”中的另一个示例。

【讨论】：

有趣的答案，但根据***.com/a/37151159 revert 确实 使用三向合并。要验证是否存在共同祖先时发生冲突，请检查指向提交 2 的新分支，还原提交 2，然后将此新分支合并到提交 3（它应该冲突）。

我对提供的链接有点困惑：'Git cherry-pick 导致合并冲突，而合并不会'它指向'***.com/questions/33063296/…'这是有意的吗？

不，可能是笔误，我回去会修复链接

在运行 3 路合并时，从技术上讲，revert 和 cherry-pick 都使用被选择或恢复的提交的父级作为共同祖先。有一种方法可以将提交应用为“纯补丁”（而不是合并），使用 git apply，您可以在此处进行正向或反向操作。如果您有一个带有 blob 哈希的 index 并使用 -3，如果直接的“应用补丁”部分失败，则应用将回退进行 3 路合并。