如何撤销分支中来自其他分支的历史错误合并并保留后续提交？

该场景最稳妥、出错成本最低的方案是基于反向revert误合并提交的方式生成新分支，全程不改动原有ABC分支的提交历史，既可以完整移除DEV分支带入的所有代码，也不会丢失ABC分支在误合并之后的所有迭代内容，具体操作步骤如下：

操作步骤 #

• 第一步：定位误合并的提交哈希
  切到本地同步到最新的ABC分支，执行命令筛选所有合并提交：

  git log --merges --oneline ABC
  

  在输出的提交记录里找到当年把DEV合并进ABC的那条合并提交，记录对应的commit hash（下文用<bad_merge_hash>代指这个值）。
  注意：合并提交默认有2个父节点，1号父节点是合并发生时ABC分支的最新提交（也就是我们要保留的主线），2号父节点是当时DEV分支的提交节点（也就是我们要移除的内容来源），后续revert需要指定这个主线编号。

• 第二步：拉取独立的新分支操作
  基于当前ABC分支的最新代码拉取全新的干净分支，所有操作都在这个新分支上执行，避免影响原有分支：

  git checkout -b ABC_fixed ABC
  

• 第三步：反向撤销误合并提交
  在新拉的ABC_fixed分支上执行revert命令，撤销那次误合并引入的所有DEV分支代码：

  git revert -m 1 <bad_merge_hash>
  

  因为距离误合并的时间较久，ABC分支后续的提交很可能修改过当时DEV带入的文件，执行命令时大概率会出现代码冲突，按以下原则处理即可：

  • 若冲突内容是ABC分支后续迭代开发的业务逻辑，直接保留当前分支（ABC_fixed）的版本
  • 若冲突内容是DEV分支当时带入、后续ABC迭代没有修改过的无关代码，直接删除对应内容
    所有冲突处理完成后，执行以下命令完成revert流程：

  git add .
  git revert --continue
  

• 第四步：校验分支正确性
  完成revert后做两类校验：

  1. 执行全量编译、自动化测试、核心业务流程回归，确认DEV分支带入的无关代码、调试逻辑、临时配置已经完全清理干净
  2. 对比ABC_fixed分支和原ABC分支的差异，确认除了DEV引入的内容被移除外，ABC分支后续所有的功能变更、配置修改、bug修复都完整保留，没有出现误删

避坑提醒 #

• 绝对不要选择回滚到误合并前的节点再批量cherry-pick后续提交的方案：当ABC分支后续提交量较大时，这种方案操作成本极高，很容易出现漏挑提交、挑错提交顺序、丢失合并节点内容的问题，出错概率远高于revert方案。
• 所有操作优先在新拉的独立分支上完成，验证通过前不要修改原有ABC分支的任何内容，哪怕操作出错只需要删除本地分支重新拉取即可，没有回滚成本。
• 如果后续需要用修复后的分支替换原有ABC分支，不要直接强推覆盖公共分支，先和团队所有在ABC分支上开发的成员同步，走正常的分支评审流程后再做替换，避免干扰其他人的本地开发环境。

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