使用`rebase-merges`基于空提交变基时为何出现合并冲突？

为什么不带--rebase-merges=rebase-cousins时变基没完成？ #

• 默认Git变基只处理当前分支的线性提交链，不会主动处理两个无共同祖先的独立根分支。你的main是空根提交，review是另一个独立根分支，Git默认不会把review的提交挪到main后面，只会保留两个分支的独立结构，所以看起来变基没完成。

为什么带--rebase-merges=rebase-cousins时会出冲突？ #

• 这个参数的作用是强制Git重构整个分支的合并历史，包括处理像review和main这种没有共同祖先的“堂兄弟分支”。执行命令时，Git会尝试把review的所有提交（包括合并节点）重新往main的空提交上套。
• review的首个提交是非空的，相当于要在完全空的仓库里一次性引入所有初始代码，Git在重构合并历史的过程中，会对原本的合并节点重新计算文件差异，这就很容易触发冲突——毕竟空提交和非空的初始提交之间没有任何共同文件基础，对比时自然会出现内容冲突。

为什么rerere没起作用？ #

• rerere的核心是复用之前解决过的冲突记录，但你现在的冲突是第一次发生：之前从来没有在main的空提交基础上应用review提交的操作，rerere根本没有对应的冲突解决记录可以调用，训练脚本自然没用。

可行的解决办法 #

• 如果不需要保留review的合并历史，直接用git rebase --onto main --root review。这个命令会把review从根开始的所有提交，全部重新应用到main的空提交之后，直接把两个独立分支变成线性结构，不会有冲突。
• 如果必须保留合并历史，那就只能手动解决这次冲突——解决完之后rerere会自动记录这次的解决结果，后续再遇到类似冲突就能自动复用了。

内容的提问来源于stack exchange，提问作者T'n'E