基于压缩提交变基时的Git冲突及重复冲突处理疑问

问题原因分析 #

你遇到的重复冲突本质是：

• 你开发时基于的非master分支，在合并到master时被压缩成了单个提交；
• 但你的本地分支里，包含了该基准分支的变更，且这些变更分散在你自己的40+个提交中；
• 变基时Git会逐个重放你的提交，每个提交都会和master里的压缩提交对比——Git无法识别这些分散提交里的变更已经存在于master的压缩提交中，所以每个提交都会触发相同的冲突。

关键疑问解答 #

1. 能不能全程用git rebase --skip？ #

绝对不行。git rebase --skip会直接跳过当前正在重放的你的提交，如果这个提交里包含你自己的独有修改，这些修改会直接丢失。只有当某一个提交的所有变更都已经完全存在于master中时，才适合用skip，但显然你的分支里有自己的开发内容，所以不能全程执行skip。

2. 手动选择current changes（master的代码）是否正确？ #

是对的。因为冲突的行并非你自己的修改，而是来自原来的基准分支——这些内容已经通过压缩提交合并到master了，所以保留master的代码（current changes）是正确的选择，不会丢失master上的有效变更。

最优处理方式 #

方式一：用git rerere自动解决重复冲突 #

这是最高效的方案，Git会记录你第一次解决冲突的方式，之后自动复用：

1. 先启用rerere（全局生效，后续所有项目都能用）：

   git config --global rerere.enabled true
   

2. 第一次遇到冲突时，手动解决（选择master的代码），然后执行：

   git add <冲突文件名>
   git rebase --continue
   

3. 之后再遇到相同的冲突，Git会自动帮你解决，无需手动操作，直接执行git rebase --continue即可。

方式二：交互式变基合并提交 #

如果你不想用rerere，可以先把自己的提交合并成少量大提交，减少冲突次数：

1. 执行交互式变基：

   git rebase -i master
   

2. 在弹出的编辑界面中，把除了第一个提交外的其他提交的前缀改成s（squash）或f（fixup），将它们合并成一个或几个大提交；
3. 保存退出后，Git会合并提交，之后只需要解决少量几次冲突即可。

方式三：直接合并而非变基（备选） #

如果变基的成本太高，可以放弃变基，直接把master合并到你的分支：

git checkout 你的分支
git merge master

这种方式只会出现一次冲突，解决后提交即可，但会在分支历史中留下合并记录，适合对提交历史要求不高的场景。

内容的提问来源于stack exchange，提问作者Farhad