误合并PR回滚后，Release分支合并Main无变更的原因及流程咨询

当你把开发分支subject-serve-image合并到main又回滚后，main分支的提交历史里已经包含了该开发分支的所有提交记录——回滚操作只是新增了一个「抵消变更」的提交，并没有删除之前的合并提交历史。

之后你把开发分支合并到rc/04，rc/04里确实有了开发分支的变更，但Git合并时是基于提交哈希的存在性判断是否需要合并：因为main已经有过这些开发分支的提交哈希，Git会认为这些变更已经处理过（哪怕被回滚了），所以合并rc/04到main时不会显示任何变更。

根据main分支是否为公共分支（是否允许强制推送），分两种情况处理：

情况1：main是公共分支（不能强制推送） #

• 误合并后回滚的正确后续操作：
  1. 找到之前误合并到main的那个合并提交的哈希值，执行回滚：git revert -m 1 <合并提交哈希>，将生成的回滚PR合并到main。
  2. 正常将开发分支合并到rc/04，完成发布准备。
  3. 要把rc/04的变更同步到main时，选择以下任一方式：
     • 方式A：撤销回滚提交：找到之前的回滚提交哈希，执行git revert <回滚提交哈希>，生成一个「取消回滚」的提交，之后再合并rc/04到main，此时Git会正常识别rc/04里的变更。
     • 方式B：Cherry-Pick开发分支提交：把subject-serve-image分支的所有提交逐个cherry-pick到main分支，再提交PR，重新应用开发分支的变更以覆盖之前的回滚。
     • 方式C：基于main同步rc/04差异：从main拉取新分支，将rc/04相对于main的差异提交cherry-pick过来，再PR到main。

情况2：main是私有分支（允许强制推送） #

• 误合并后直接回退main到合并前的状态：
  1. 找到合并前main分支的最新提交哈希，执行git reset --hard <合并前哈希>。
  2. 强制推送到远程main：git push -f origin main。
  3. 之后正常执行rc/04合并到main的PR即可，此时main的提交历史完全回到误合并前，Git会正常识别rc/04里的所有变更。

• 合并PR前务必仔细核对目标分支，避免误操作。
• 对于公共分支，优先用revert处理误合并，避免使用reset这类修改历史的操作，但要注意后续同步分支时的提交历史冲突问题。
• 可在仓库设置中添加分支保护规则，比如限制main分支的合并来源、要求审核人审批等，减少误操作概率。

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