Git将dev变基到main后二者超前滞后提交数一致的原因及优化方案

• 对GitHub「Rebase and Merge」的功能理解错误：GitHub网页端的Rebase and Merge并不会直接复用源分支的原有提交，而是会在目标分支上重新生成所有待合并的提交。哪怕提交内容、作者信息、提交说明完全和源分支一致，也会因为操作触发的时间戳、committer标识的差异，生成完全不同的commit哈希值。Git判断分支历史是否一致完全依赖commit哈希，只要哈希不同，就算内容完全相同也会被识别为独立提交。
• 对跨分支提交同步的逻辑理解错误：你从dev合并到main生成了新哈希的提交后，dev上的原有提交和main上的新提交没有关联关系，就会出现dev超前N个自己的旧提交、滞后N个main上的新提交的情况，二者数值完全相等就是这个原因。

你可以根据自己的团队习惯选择以下任意一种方案，都可以彻底解决当前问题：

方案1：保留现有开发流程，仅修改发布到main的操作 #

这是改造成本最低的方案，不需要调整开发阶段的工作流：

• 功能开发、合并到dev的规则保持不变，仍然按你的习惯用Squash and Merge（多提交）或Rebase and Merge（单提交）
• 发布版本时不要用GitHub网页的Rebase and Merge按钮，改用本地快进合并后推送：
  1. 本地拉取最新的远程代码：git fetch origin
  2. 切换到main分支：git checkout main
  3. 执行纯快进合并：git merge --ff-only origin/dev
  4. 推送本地main到远程：git push origin main
     这个操作会完全复用dev的提交哈希，不会生成新提交，两个分支的历史会完全一致，不会出现超前滞后的问题。

方案2：全网页操作的适配方案 #

如果你不想做本地操作，完全依赖GitHub网页完成所有合并，可以调整流程：

• 开发阶段合并到dev的规则保持不变
• 发布版本时仍然用GitHub的Rebase and Merge把dev合并到main
• 合并完成后直接在GitHub上开一个从main指向dev的PR，用Rebase and Merge合并，就能把main上生成的新提交同步到dev，不需要本地执行强制推送操作。

方案3：极简同步方案 #

如果你的团队不需要在main分支上做任何独立提交，main的内容完全和dev的发布版本对齐，可以直接用分支推送同步：

• 每次要发布版本时，确认dev分支的状态符合发布要求后，直接执行git push origin dev:main，会把dev的所有提交直接同步到main分支，二者哈希完全一致，没有额外的合并操作。

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