同一分支间多次用Rebase and Merge创建GitHub PR出现虚假冲突

核心本质：GitHub的Rebase and Merge并非本地Rebase #

你的理解完全正确——GitHub的Rebase and Merge并不是执行本地git rebase那种「移动原分支提交到目标分支顶端」的操作，而是将PR中的所有提交逐个cherry-pick到目标分支的最新版本上，生成全新的提交（哈希值和原提交完全不同），再将目标分支指针指向这些新提交。

这种设计的目的是：既保持目标分支（比如master）的线性历史，又避免对目标分支执行强制推送（很多仓库禁止对主分支强制推送）。但代价就是：原开发分支（比如你的develop）的提交历史和目标分支彻底脱节了。

你遇到的问题根源 #

第一次合并后：

• develop分支的历史：C1(lorem) → C2(阿西莫夫) → C3(丹·西蒙斯)
• master分支的历史：C1 → C2'(阿西莫夫，复制提交) → C3'(丹·西蒙斯，复制提交)

当你在develop上继续提交C4(弗兰克·赫伯特)，develop的历史变成C1→C2→C3→C4，但master的历史是C1→C2'→C3'。此时第二次PR的对比逻辑是：

1. GitHub会找develop和master的最近共同祖先——也就是C1
2. 所以PR会把C2、C3、C4都标记为「待合并提交」，哪怕C2、C3已经通过复制提交合并到master了
3. 文件对比的base是C1的内容（lorem），而master当前是C3'的内容，自然会出现冲突，还显示错误的对比逻辑

解决方法：合并后同步开发分支与目标分支 #

如果要继续用Rebase and Merge模式多次提PR，每次合并完成后必须同步develop分支：

1. 拉取master的最新代码：git checkout master && git pull
2. 切换回develop分支，执行rebase：git checkout develop && git rebase master
   • 这一步会把develop的C4提交「移动」到master的C3'顶端，生成新的C4'提交，develop的历史变成C1→C2'→C3'→C4'
3. 强制推送到远程develop分支：git push -f origin develop
   • 因为rebase改变了历史，必须强制推送（确保你有develop分支的推送权限）

之后再在develop上提交代码、提PR，就不会出现旧提交重复显示、对比错误的问题了。

补充说明 #

• 同一分支完全支持多次使用Rebase and Merge，只是必须同步分支历史，否则就会出现你遇到的问题。
• 如果觉得同步分支麻烦，也可以考虑其他合并方式：
  • Squash and Merge：把PR的所有提交合并成一个新提交到目标分支，适合小功能迭代。
  • Create a merge commit：保留合并提交，分支历史会有分叉，但不需要同步开发分支，适合多人协作场景。

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