Git仓库棘手问题：如何移除引发异常的合并提交M1

看起来你是因为合并提交M1引入了问题，想要彻底移除它对吧？根据你的仓库结构，我给你两种可行的解决方案，分别适用于不同的场景：

方案一：交互式变基（适合本地未推送/团队能配合重写历史） #

这种方法会直接修改Git历史，把M1从分支中彻底移除，适合还没把分支推送到远程，或者团队成员都能配合同步历史的情况。

• 首先切换到develop分支：

  git checkout develop
  

• 查看提交日志找到M1的哈希值（简洁日志模式更易定位）：

  git log --oneline
  

  输出里会看到类似abc123 M1: Merge branch 'TPQ' into develop的行，abc123就是M1的哈希值。
• 启动交互式变基，目标指向M1的前一个提交（也就是M1合并之前的分支状态）：

  git rebase -i abc123^
  

• 在弹出的编辑器中，找到M1对应的那一行，把开头的pick修改为drop（或者直接删除该行），保存并退出编辑器。
• 此时Git会尝试把M1之后的提交（比如你的B提交）重新应用到移除M1后的分支上。如果遇到冲突：
  1. 手动打开冲突文件，解决其中的冲突标记（<<<<<<<、=======、>>>>>>>）
  2. 标记冲突已解决：

     git add <冲突文件名>
     

  3. 继续完成变基流程：

     git rebase --continue
     

• 如果你的master分支已经通过M2合并了包含M1的develop，需要对master做同样的处理：
  1. 切换到master分支：

     git checkout master
     

  2. 找到M2的哈希值，启动变基到M2的前一个提交：

     git rebase -i M2^
     

  3. 把M2对应的行改成drop，保存退出后，后续的C、D提交会被自动重新应用。
• 最后如果需要推送到远程，因为我们修改了历史，需要用安全的强制推送（--force-with-lease比单纯的--force更稳妥，避免覆盖他人未同步的提交）：

  git push --force-with-lease
  

方案二：撤销合并提交（适合已推送且团队无法配合重写历史） #

如果分支已经推送到远程，且团队其他成员已经拉取过该分支，直接修改历史会导致大家的仓库状态不一致。这种情况下，用git revert创建一个抵消M1的新提交是更友好的选择。

• 切换到develop分支：

  git checkout develop
  

• 执行撤销合并的命令，这里的-m 1是指定以合并提交的第一个父分支为基准（也就是develop在合并TPQ之前的状态），撤销合并进来的内容：

  git revert -m 1 <M1的哈希值>
  

  如果你不确定父分支，可以用git show M1查看输出，第一个parent对应的就是基准分支。
• 编辑器会自动打开让你填写撤销提交的说明，默认内容即可，保存退出。
• 此时Git会生成一个新的提交，这个提交会抵消M1合并带来的所有代码变化，历史不会被修改，团队成员只需要正常拉取即可同步。
• 如果master分支已经通过M2合并了有问题的develop，你可以选择把develop上的撤销提交合并到master，或者直接在master上执行git revert -m 1 M2来撤销M2的合并。

重要提醒 #

• 操作前建议先创建备份分支，以防操作失误可以快速恢复：

  git checkout -b develop_backup
  

• 如果选择重写历史（方案一），一定要提前和团队成员沟通，让他们知道需要同步新的历史（比如执行git fetch origin && git reset --hard origin/develop）。
• 处理冲突时要仔细核对代码，确保最终的代码逻辑符合预期。

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