为何合并stage到main后GitHub提示创建main到stage的Pull Request？

以下是导致该问题的常见原因及对应解决思路：

1. 合并方式导致提交历史不一致 #

将stage分支合并到main分支时，若使用**创建合并提交（Create a merge commit）**的默认PR合并方式，main分支会生成一个新的合并提交，但stage分支不会包含这个提交。此时两个分支代码内容完全一致，但提交历史存在差异，GitHub会检测到main分支比stage分支多了一个提交，因此触发从main到stage的PR提示。

解决办法：

• 合并时选择快进合并（Fast-forward merge）：由于你的开发流程中所有代码变更都先合并到stage，main分支在合并前不会有独立提交，这种方式不会生成新提交，合并后main和stage会指向同一个提交哈希，消除差异提示；
• 合并完成后同步stage分支：执行git checkout stage && git merge main，此时main是stage的超集，会自动完成快进合并，让两个分支完全对齐。

2. 使用 squash/rebase 合并改写main分支历史 #

如果合并stage到main时用了压缩提交（Squash and merge）或变基合并（Rebase and merge），这两种方式都会改写main分支的提交历史：

• Squash会把stage的多个提交压缩成一个新提交放到main上，导致main的提交哈希与stage原始提交完全不同；
• Rebase会把stage的提交移到main当前HEAD之后，生成全新的提交哈希。
  即便代码内容一致，提交历史的差异也会让GitHub判定两个分支存在区别，触发PR提示。

解决办法：

• 优先使用快进合并或普通合并提交，合并后同步stage分支；
• 若必须使用squash/rebase，合并main后需将main内容同步到stage（注意：确保stage无未合并的开发提交），执行git checkout stage && git reset --hard main，再推送到远程仓库。

3. 默认分支设置的影响 #

你将stage设为默认分支，GitHub的PR提示逻辑会基于默认分支对比其他分支。当main分支出现新提交（比如合并生成的提交），就会触发从main到默认分支stage的PR提示，哪怕代码内容完全一致。

解决办法：

• 合并main后及时同步stage分支，让两者提交哈希保持一致，从根源消除差异；
• 无需调整GitHub全局设置，保持分支同步是最稳妥的方案。

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