Git长分支211次提交压缩变基遇500+冲突，求高效解决方案

一、无需新建分支的提交压缩方案（规避rebase冲突） #

不用git rebase -i，改用git reset --soft直接合并所有提交为一次，步骤如下：

1. 先备份当前分支（防止操作失误）：

   git branch feature-branch-backup
   

2. 找到特性分支从origin/master分出的起始提交哈希：

   git merge-base feature-branch origin/master
   

   把输出的哈希记为<START_COMMIT>
3. 执行软重置，保留当前分支的所有修改，但回到起始提交的状态：

   git reset --soft <START_COMMIT>
   

4. 提交压缩后的单次版本：

   git commit -m "你的压缩提交信息：比如「完成XX长期特性开发」"
   

5. 安全强制推送到远程（避免覆盖他人提交）：

   git push --force-with-lease origin feature-branch
   

   注意：推送前务必和基于该分支提交PR的同事沟通，让他们先拉取更新后的分支

二、为什么rebase会产生远多于merge的冲突？ #

• git merge是将当前分支的最终状态与origin/master的最新状态做一次合并，只需要解决一次两个最终版本之间的冲突。
• git rebase -i HEAD~210是把你的211次提交逐个重播到origin/master的最新版本上，每次重播都要和master的变更对比：如果同一个文件在多次提交中都有修改，且master也改了这个文件，那么每次重播都可能触发冲突，多次冲突叠加后数量就会远高于merge的冲突数（比如你提到的4个文件反复冲突，就是因为这4个文件在多个提交里都有修改，每次重播都要处理一次）。

三、为什么git rerere没起到作用？ #

git rerere的作用是记录完全相同的冲突场景的解决结果，复用之前的解决方案。但rebase时，每次重播提交遇到的冲突，哪怕是同一个文件，冲突的上下文（比如冲突行的位置、周围代码内容）可能因为前面的提交已经修改过文件而发生变化，属于不同的冲突场景，所以rerere无法复用之前的解决结果，自然没明显作用。

四、同事PR的兼容处理 #

如果同事已经基于旧分支提交了PR，让他们执行以下操作调整自己的分支：

1. 拉取远程更新后的feature-branch：

   git fetch origin
   

2. 把自己的分支（比如their-pr-branch）重新基于新的压缩分支：

   git rebase --onto origin/feature-branch feature-branch-backup their-pr-branch
   

3. 强制推送自己的PR分支：

   git push --force-with-lease origin their-pr-branch
   

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