执行git rebase master时仅本地分支文件冲突的问题求助

核心原因 #

master的历史被改写（squash、drop、编辑提交）后，你分支与master的公共祖先已不存在。Git在默认rebase时会尝试对比被修改的旧master历史，导致误判你分支独有的文件为冲突；重复冲突则是因为多个提交涉及同一文件，或冲突解决未被Git复用。

分步解决方案 #

1. 先备份分支，避免操作失误 #

git checkout other_branch
git branch other_branch_backup

2. 使用git rebase --onto跳过无效的旧master历史 #

这个命令能直接把你分支的所有新增提交，移植到被改写后的新master上，跳过已失效的旧公共祖先，从根源减少不必要的冲突：

# 1. 找到你分支从master分出时的旧master提交哈希（记为old_master_hash）
# 方式：查看你分支的第一个提交的父提交
git log --oneline other_branch --reverse | head -2
# 输出中第二行的父提交哈希就是old_master_hash（格式类似abc123）

# 2. 获取当前master的最新提交哈希（new_master_hash）
git log --oneline master -n 1
# 输出的哈希就是new_master_hash

# 3. 执行定向rebase
git rebase --onto new_master_hash old_master_hash other_branch

如果找不到精确的old_master_hash，可尝试用git merge-base other_branch master@{1.month.ago}获取一个接近的历史节点替代。

3. 用rerere自动复用冲突解决结果 #

开启Git的冲突记忆功能，解决一次冲突后，后续相同冲突会自动处理：

# 全局开启rerere
git config --global rerere.enabled true

# 若当前rebase卡在冲突中，先终止再重启
git rebase --abort
git rebase master  # 或用上面的--onto命令

解决冲突后执行git add <冲突文件>，再git rebase --continue，Git会记录你的解决方式，后续重复冲突自动完成。

4. 清理分支中的无效合并记录 #

你之前执行的merge master会在分支中引入master的历史提交，导致后续rebase混乱。可通过交互式rebase清理这些合并提交：

git rebase -i --rebase-merges master

在弹出的编辑界面中，将涉及master合并的提交标记为drop或squash，精简分支历史。

5. 优化你的rebase工作流 #

去掉不必要的git pull other_branch（仅当多人协作该分支时需要），改为：

git checkout master
git pull origin master
git checkout other_branch
git rebase master

关键注意事项 #

• master历史被改写后，所有基于旧master的分支都需要重新同步，禁止使用普通git pull，必须用rebase --onto或重新基于新master创建分支。
• 若分支提交过多（147个），建议先通过交互式rebase合并相关提交，减少rebase时的冲突次数：

  git rebase -i old_master_hash other_branch
  

  在编辑界面中将多个相关提交标记为squash或fixup，合并为少量提交后再执行rebase --onto。

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