master分支历史被篡改后，rebase my_branch时重复冲突如何解决？

• master分支历史被改写：当master通过git rebase、git reset、强制推送等操作改写历史后，my_branch与master的公共祖先节点已失效。变基时Git需要将my_branch的所有提交重新应用到新的master顶端，而这些提交中的文件可能在master的改写历史中被删除、重命名或修改，Git无法识别历史变更的上下文，导致每次应用提交都会触发相同冲突。
• 分支独有文件的历史冲突：你在my_branch中新增的文件，在master的改写操作中可能被误删除或出现同名文件的修改，Git合并时无法判断文件归属，重复触发冲突。
• 冲突未彻底解决：变基过程中若仅部分解决冲突、未用git add标记冲突已解决就继续，Git会认为文件状态仍有歧义，后续提交应用时重复触发相同冲突。

方案一：一次性合并替代逐次变基（推荐） #

这种方式能避免重复解决相同冲突，效率更高：

1. 备份当前分支，防止操作失误：

   git checkout my_branch
   git checkout -b my_branch_backup
   

2. 将my_branch重置到master最新状态，再合并备份分支的所有修改：

   git checkout my_branch
   git reset --hard master
   git merge --no-ff my_branch_backup
   

3. 此时只会触发一次冲突，解决所有冲突后提交即可。完成后my_branch的所有修改就基于最新master，后续可正常变基。

方案二：逐次变基时彻底解决冲突 #

若必须保留提交历史：

1. 启动变基：

   git rebase master
   

2. 遇到冲突时，打开冲突文件解决所有内容差异。
3. 解决后标记文件已解决：

   git add <冲突文件名>
   

4. 修改当前正在应用的提交，确保冲突解决后的状态被正确记录：

   git commit --amend
   

5. 继续变基：

   git rebase --continue
   

   此操作会将解决后的状态作为该提交的新内容，后续提交应用时不会重复触发同一冲突。

方案三：交互式变基合并相关提交 #

如果my_branch中有多个提交修改同一批文件，可先合并提交减少冲突次数：

1. 启动交互式变基：

   git rebase -i master
   

2. 在弹出的编辑器中，将除首个提交外的其他提交的pick改为s（squash），将它们合并为一个提交。
3. 保存退出后，Git会合并这些提交，此时只需解决一次冲突即可完成变基。

注意事项 #

• 禁止在公共分支（如master）上改写历史，团队需统一遵守此规范。
• 定期将开发分支变基到master，避免长时间积累大量历史差异。
• 变基前务必备份分支，防止操作失误丢失代码。

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