GitHub合并Feature、Develop、Main分支如何避免领先/落后差异

核心根因 #

所有分支不同步的本质，是各类GitHub合并操作会在目标分支生成和源分支Git哈希完全不同的独立提交：哪怕提交对应的代码逻辑、文件内容100%一致，Git也会将其识别为毫无关联的两个独立节点，最终出现分支间领先、落后的计数差，甚至出现PR混杂历史提交的异常。

• 对应Squash Merge流程的问题：从Feature分支合并到Develop时，会在Develop上生成一个全新哈希的squash提交；后续再从Develop往Main做squash合并时，会在Main上再生成一个全新哈希的同内容squash提交。此时Git识别到两个分支各有一个对方没有的同内容提交，就会出现Main相对Develop“1个领先、1个落后”的显示。
• 对应普通Merge流程的问题：从Feature合并到Develop时生成的合并提交属于Develop的提交链；后续从Develop往Main做普通合并时，GitHub会自动额外生成一个新的独立合并提交，这个提交不在Develop的提交链上，就会出现Main相对Develop“1个领先”的显示。之前遇到的新PR混杂旧提交的问题，也是因为两个分支提交链从早期squash步骤就已经分叉，Git会将分叉点后两边所有独立生成的提交都纳入PR的待合并列表，哪怕这些提交的代码内容完全重复。

纯GitHub界面PR操作的调整方案（无需手动执行CLI命令） #

1. 从根源避免分叉的合并规则配置 #

通过仓库的分支保护规则，给不同分支匹配专属的合并权限，杜绝跨分支重复生成独立提交的问题：

• 对Develop分支：开启仅允许Squash and Merge合并的规则，将所有合入源限制为Feature功能分支。这一步和现有流程完全一致，把Feature的零散commit压缩为单个干净的提交，保持Develop提交链的整洁。
• 对Main分支：开启Require linear history（强制线性提交历史）规则，关闭Squash Merge、普通Merge（会生成额外独立合并提交）的权限，仅允许Rebase and Merge方式合入，且合入源仅允许是Develop分支。
  这个规则生效后，从Develop往Main合生产版本时，GitHub不会生成任何全新的合并节点或squash节点，只会把Develop上已有的提交逐个“平移”到Main的最新提交节点上。由于合入前Main的最新提交就是上一次发布时和Develop对齐的节点，平移后的提交元数据（作者、提交时间、提交信息、代码内容）会和Develop上的对应提交完全一致，生成的Git哈希也完全相同。此时Main和Develop的提交链会严格对齐，不会出现任何领先、落后的计数差。

2. 存量分叉的一次性清理方法 #

如果已经因为之前的合并操作产生了提交链分叉，全程用PR操作即可完成对齐，不需要命令行操作：

• 首先从Develop分支发起一个指向Main的PR，用Rebase and Merge方式合入，让Main的代码内容完全和最新Develop对齐。
• 合入完成后，再从Main分支发起一个指向Develop的PR，同样用Rebase and Merge方式合入，让Develop的代码内容完全和最新Main对齐。
• 两次合并完成后，两个分支的文件状态和提交链会完全匹配，后续按照上述规则操作就不会再出现分叉问题。

3. 兜底同步操作 #

如果临时需要调整合并规则、不想改动长期配置，可以在每次完成Develop到Main的生产合并后，直接在仓库的分支管理页面找到Develop分支，点击页面上的Update from Main按钮，GitHub会自动生成一个同步PR，将Main上独有的提交同步到Develop分支，合并完成后即可消除领先、落后的计数差，全程不需要手动敲命令。

避坑提示 #

• 绝对禁止绕过PR往Main或Develop分支直接推送提交，所有合入操作必须走PR流程，避免分支提交链出现意外分叉。
• 不要在Develop分支上直接提交和功能开发无关的临时修改，所有Develop的提交必须来自Feature分支的合并，保证Develop是Main所有生产变更的唯一上游。

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