git revert -m 1 可安全回滚合并提交，需指定主线父提交以避免冲突； revert 后须及时修复并撤销 revert 提交，防止后续合入失效。
公共分支上误合了代码？别动 git reset，直接用 git revert —— 它不删历史、不扰他人、推送即生效。
为什么 revert 合并提交比普通 commit 更容易出错
合并提交（merge commit）有至少两个父提交，Git 默认不知道该“以谁为基准”去反向计算更改。如果你直接 git revert <merge-commit-hash>，Git 会报错：error: Commit <hash> is a merge but no -m option was provided。
这不是 bug，是设计：Git 要求你明确指定「主线父提交」（mainline parent），也就是你日常开发所基于的那个分支（比如 main 或 develop），否则它无法判断哪些改动是“外来引入的”，哪些是“本地已有的”。
- 通常，第一个父提交（
-m 1）是你当前所在分支在合并前的最新提交（即主线） - 第二个父提交（
-m 2）是被合并进来的分支 tip（即 feature 分支最后一次提交） - 想撤销整个 feature 分支的改动 → 用
-m 1；想撤销“把 main 合入 feature”的操作（极少见）→ 用-m 2
如何安全 revert 一次多人协作后的 merge 提交
假设你在 main 上执行了 git merge feature/login，现在发现这个功能有严重问题，需要回滚：
- 先查合并提交 ID：
git log --oneline -n 10，找到形如abcd123 Merge branch 'feature/login'的那条 - 确认主线是
main→ 所以要用-m 1：git revert abcd123 -m 1 - Git 会自动生成提交信息
Revert "Merge branch 'feature/login'"，建议手动补上原因和工单号，比如：Revert "Merge branch 'feature/login'" (#FE-456) —— 登录态 token 泄露风险，待修复后重合
注意：如果合并后 main 上还有其他提交，revert 只撤销那次 merge 引入的 diff，不影响后续修改。
监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。
revert 失败时最常遇到的三个冲突点
revert 不是万能的自动操作，尤其当被 revert 的提交和当前代码有重叠修改时，Git 会暂停并提示冲突：
-
git status显示文件状态为both modified，不是unmerged—— 这是 revert 冲突的典型信号 - 冲突标记仍是标准格式：
<<<<< HEAD（当前代码）、=======（分隔线）、>>>>> Revert ...（要撤销的原始变更） - 解决完所有冲突后，**必须**运行
git add <file>标记为已解决，再执行git revert --continue；若中途想放弃，用git revert --abort
特别提醒：revert 合并提交时若发生冲突，Git 不会告诉你冲突来自哪个父分支 —— 你需要自己对照原 merge 提交的 diff（git show <merge-hash>）来判断哪部分该保留。
线上紧急回滚后，真正关键的下一步是什么
revert 提交推送到远程后，服务可能暂时恢复正常，但这只是“止血”，不是“根治”。最容易被忽略的是：
- 这个 revert 提交本身成了新历史的一部分，后续再合入修复版
feature/login时，Git 会认为“相关改动已存在”，可能跳过关键 patch —— 必须用git revert先撤销掉那个 revert 提交（即 revert revert），再合入修复 - 团队内部需同步：在 PR 描述或群消息里明确写出 “已 revert
abcd123，修复 PR 待合入 #FE-456-fix” - CI/CD 流水线若对 revert 提交做了特殊处理（如跳过测试），要检查是否误放行了带缺陷的代码
revert 的安全，只在于不破坏历史结构；它的代价，是让历史变复杂。越早补上真正修复，越少陷入“revert 套娃”。
