在什么情况下，对HEAD~10的重组会产生冲突？

Question

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

根据我的理解，上面的命令应该恢复到HEAD~10，然后cherry-pick每次提交，然后通过它而不做任何更改，因此只需重复历史记录。

如何产生合并冲突？

我不会发布具体案例，因为我不想将这个问题转化为具体的解决问题（我实际上没有理由这样做rebase），但我宁愿试图理解git工作。

修改

添加网络图，以更好地说明事情。当rebase达到“More tests”commit

时，就会发生冲突

Answer 1

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

Answer 2

正如我在＆＃34; Why does this cherry-pick have a conflict?＆＃34;中详细解释的那样，在以下情况下尝试使用相同的rebase：

git config merge.conflictstyle diff3

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

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