合并含main分支误合并revert提交的release分支如何避免影响main分支

问题根因 #

你遇到的确实是Git的预期行为：当你把main分支合并到release后又revert了这个合并提交时，Git会将该revert提交识别为「主动丢弃本次合并带入的所有main分支改动」，并不会记录这是操作失误导致的回退。后续将release合并回main时，Git会默认应用这个revert提交的改动，就会清空main上对应范围内的新增内容。
以下是不需要强制修改核心分支历史的可行方案：

解决方案 #

• 方案1：在release分支上撤销错误的revert提交（推荐长期使用） #

  适合后续还要持续维护release分支、需要多次合并到main的场景：
  1. 从当前release分支拉取独立的修改分支，避免直接修改核心release分支
  2. 在新分支执行 git revert <错误回退合并的revert提交哈希值>，相当于把之前误撤销的main分支改动再恢复回来
  3. 验证分支内容符合预期后，通过PR将该改动合并到release分支
  4. 后续再将release合并到main时，就不会出现main原有内容被删除的问题

• 方案2：合并到main时指定忽略revert提交 #

  适合不想改动release分支、只需要处理本次合并的场景：
  1. 从最新的main分支拉取独立的合并分支
  2. 执行 git merge -s ours <错误的revert提交哈希值>，该命令会告知Git不需要应用该revert提交的任何改动，直接标记为已合并
  3. 执行 git merge <当前release分支名> 完成全量合并
  4. 验证文件内容符合预期后，通过PR将合并后的分支提交到main即可

• 方案3：挑拣release上的有效提交到main #

  适合release分支上除了误操作的两个提交外，有效改动提交数量较少的场景：
  直接执行 git cherry-pick <需要同步的bug修复提交哈希值>，将需要的改动逐个同步到main分支，完全跳过误合并和对应的revert提交，不会影响main的原有内容

后续规避建议 #

• 所有PR合并前必须预览改动范围，确认提交列表中没有针对main分支合并的回退操作
• 给release分支添加合并限制，禁止非发布流程触发的main到release的合并操作

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