什么时候需要回滚合并请求
上周五下午，团队刚上线一个新功能，结果没过两小时，用户反馈系统卡顿，订单提交失败。排查发现是某个合并请求把数据库查询写成了全表扫描。这时候最快速的补救方式不是修 bug，而是立刻回滚那个合并请求。
在 Git 工作流中，合并请求（Merge Request）被接受后，代码就进入主分支。一旦发现问题，直接修改不如回滚来得稳妥。尤其在发布前夜或节假日，回滚能避免连锁故障。
通过 Git 命令回滚合并
假设你已经定位到要回滚的合并提交，它的 commit hash 是 abc1234。因为合并提交有两个父节点，普通 revert 不够用，得加上 -m 参数指定主分支方向。
执行以下命令：
git revert -m 1 abc1234这里的 -m 1 表示保留第一个父提交的内容，也就是合并前主分支的状态。如果你不确定哪个是主分支，可以用 git show abc1234 查看，第一个列出的 parent 就是主分支。
处理冲突与提交
回滚过程中可能出现冲突，尤其是被合并的代码改动了公共文件。Git 会暂停并提示你手动解决。改完后执行：
git add .
git revert --continue完成后推送到远程：
git push origin main使用 GitLab/GitHub 界面快速回滚
如果团队用的是 GitLab，打开对应的合并请求页面，往下翻，能找到一个「Revert」按钮。点一下，它会自动创建一个新的合并请求，内容就是对原提交的 revert。
这个方式的好处是流程清晰，审批链完整，适合规范较严的项目。而且生成的 revert MR 可以先检查再合并，避免误操作。
GitHub 上类似，进入 Pull Request 的 Commits 标签页，找到目标提交，点击右侧的「...」菜单，选择「Revert this commit」，然后按提示创建新的 PR。
回滚后别忘了通知队友
有一次我默默回滚了一个有问题的合并，结果同事还在基于那部分代码开发新功能，第二天拉代码发现冲突一堆。从那以后，只要做了回滚，我都会在群里发一条消息：「已回滚 MR !123，原因：导致登录接口超时，新修复走 MR !125」。
顺便提一句，回滚不是丢脸的事。就像做饭糊了锅，赶紧关火比硬着头皮端上桌强。关键是要快，要准，要留痕迹。
预防胜于回滚
虽然回滚很方便，但最好别总用。建议在 CI 流程里加个「合并前检查」，比如单元测试覆盖率不低于 80%，关键接口必须有压测报告。我们项目现在还要求每个 MR 至少两人评审，主分支保护规则也设好了，不能绕过 CI 直接合并。
另外，小步提交比大块堆代码更容易维护。一个 MR 改动超过 500 行，出问题时定位和回滚都费劲。拆成几个小 MR，就算要回，也能精准切除病灶。