合并到master后rebase全文件冲突问题及解决方案咨询

场景 #

基于需求创建新分支，开发时每次提交执行以下命令：

• git add .
• git commit -m "comment"（提交变更到分支）
• git pull --rebase origin master（将分支与master变基）
• git fetch
• git push -f origin <branch_name>
  完成开发后提交Pull Request，审核通过后以普通合并或squash合并方式合并到master分支。

问题 #

将分支合并到master后，再次在该分支执行git pull --rebase origin master时，所有曾修改过的文件都出现冲突，无法一次性解决，必须针对每一次提交重复修改文件才能完成rebase。

解决方案与流程调整建议 #

1. 冲突产生的核心原因 #

当你的分支通过普通合并或squash合并到master后，master的提交历史里并没有包含你分支原有的提交记录：

• 普通合并会生成一个新的合并提交，你分支的原有提交还是独立存在的；
• squash合并会把你分支的所有提交压缩成一个全新的提交，原分支的提交历史完全不会进入master的历史中。

这时候再对该分支执行rebase，Git会尝试把你分支原有的所有提交重新“贴”到最新的master上面，但这些变更其实已经通过合并/squash进入master了，自然会触发大量重复冲突。

2. 直接避免冲突的操作方式 #

• 最推荐：不要复用已合并到master的分支
  分支合并到master后，它的使命就完成了，直接删掉本地和远程分支就行。如果有新的需求，直接基于最新的master创建新分支开发，从根源上避免这个问题。
• 如果实在要复用（非常不推荐）：
  先把分支彻底重置到master的最新状态，扔掉原分支的所有提交历史：

  git checkout <branch_name>
  git reset --hard origin/master
  

  之后再在这个干净的分支上开发，就不会有历史提交导致的冲突了。

3. 现有开发流程的优化点 #

• 简化提交阶段的命令
  git pull --rebase本身就包含了git fetch的操作，所以你的命令可以简化，去掉冗余的git fetch：

  git add .
  git commit -m "comment"
  git pull --rebase origin master
  git push -f origin <branch_name>
  

  或者拆分成更清晰的两步：

  git add .
  git commit -m "comment"
  git fetch origin master
  git rebase origin/master
  git push -f origin <branch_name>
  

• PR合并后强制清理分支
  在PR合并完成后，直接执行命令删掉分支：

  # 删除本地分支
  git branch -D <branch_name>
  # 删除远程分支
  git push origin --delete <branch_name>
  

  从流程上堵死复用旧分支的可能。
• 如果团队接受，改用rebase合并PR
  PR合并时选择rebase合并方式，这样你的分支提交会直接追加到master的历史中，不会生成合并提交或squash提交。之后哪怕不小心复用分支，rebase时也不会出现大量冲突。但要注意，rebase合并会改写master的提交历史，需要整个团队达成共识，并且大家都熟悉相关操作。

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