在什么情况下 rebase 到 HEAD~10 会产生冲突？答案

【问题标题】：In what case might a rebase to HEAD~10 produce conflicts?在什么情况下 rebase 到 HEAD~10 会产生冲突？
【发布时间】：2017-03-25 19:10:15
【问题描述】：

我有一个案例，只是执行git rebase HEAD~10 会产生多个合并冲突。

据我了解，上面的命令应该恢复为HEAD~10，然后是cherry-pick，此后每次提交都没有任何更改，因此只是重复历史。

这怎么可能产生合并冲突？

我不会发布具体案例，因为我不想把这个问题变成具体的问题解决方案（我实际上没有理由这样做rebase），但我更想了解 git 是如何工作的.

编辑：

添加网络图，以更好地说明问题。当变基达到“更多测试”提交时，就会发生冲突

【问题讨论】：

标签： git rebase

【解决方案1】：

如果您的最后 10 个提交包含合并提交，则可能会发生这种情况。除非您指定 --preserve-merges / -p ，否则默认情况下变基会将历史记录线性化，从而消除历史记录中合并提交导致的任何合并冲突结果，因此您将再次遇到这些冲突。

【讨论】：

请注意，如果您在使用 git rebase -p 重放的合并中解决了冲突，Git 将必须在同一合并中解决相同的冲突。原因是“合并保留”实际上是“合并重做”。如果您启用了git rerere，Git 将重新使用您现有的记录解决方案，但我们大多数人不会并且必须手动重新执行冲突解决方案。
实际上在历史记录中还有一个合并 1 提交。我不记得这是否需要解决冲突，这是可能的。然而，当应用“更多测试”而不是“首次成功分析”时出现冲突的事实仍然困扰着我

【解决方案2】：

正如我在“Why does this cherry-pick have a conflict?”中详细解释的那样，之后尝试相同的变基：

git config merge.conflictstyle diff3

您将看到（在 rebase 期间应用樱桃挑选后发生冲突时）没有共同的祖先。

Cherry-picking 接受提交并应用它引入的更改。
这意味着如果引入的更改是在目标没有的其他更改之上引入的......冲突。
（同样，“Why does this cherry-pick have a conflict?”说明了这种情况）

【讨论】：

如果这是问题的原因，OP 可以通过将--merge / -m 传递给git rebase 使其“使用合并策略来变基”来解决它。
您是说它不知道是在“一些测试”还是“首次成功分析”之上应用“更多测试”？（上图）
@qwazix 它知道要应用什么提交，而不是该提交中的内容：阅读stackoverflow.com/a/38989749/6309
我确实读过，但在那种情况下，OP 会尝试将一个提交应用到一个状态多次提交。它不会成功是非常合乎逻辑的，因为它找不到在哪里进行更改。就我而言，它只是在前一次提交上重放提交，因此 AIUI 不可能不知道要应用什么内容。
@qwazix 你试过激活git config merge.conflictstyle diff3吗？发生冲突时，您在共同祖先部分看到了什么？