必须指定 -m 1，因为合并提交有两个父节点，git 无法自动判断以哪个为基准生成反向变更；-m 1 表示保留第一个父提交（主分支）代码，撤销被合并分支的全部更改。

git revert -m 1 为什么必须指定，不加会报错

直接运行 git revert <merge-commit-hash></merge-commit-hash> 会失败，报错类似 error: commit <hash> is a merge but no -m option was specified</hash>。Git 不知道该以哪个父提交为“基准”来生成反向变更——合并提交有两个父节点，它没法猜你想要保留哪条线的逻辑。

绝大多数误合并场景下（比如把 feature/payment 错合进 main），你要保留的是 main 当前状态，也就是第一个父提交（即合并前 main 的 HEAD）。所以必须加 -m 1。

• -m 1：撤销被合并分支引入的所有变更，主干代码不变
• -m 2：反过来，保留被合并分支的代码，丢弃主干后续修改（极少用，慎用）
• 不确定时先查：运行 git show --pretty=raw <merge-commit-hash></merge-commit-hash>，看 Merge: 行两个哈希谁在前——前面那个就是 -m 1 对应的父提交

已推送的合并被多人拉取后还能安全 revert 吗

能，而且这正是 git revert 的核心价值所在。只要没人对那个错误合并之后的 main 做过强制推送（push --force），就完全安全。

revert 本质是新增一个提交，不改任何已有 commit 的 SHA-1。所有协作者下次执行 git pull，都会自动拿到这个新提交，历史线性增长，无冲突、无重写、无需协调。

openclaw-gitcode-pr-monitor

监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。

下载

• 别人本地已有该 merge 提交？→ 拉取后自动包含 revert，效果立即生效
• 别人已在该 merge 后提交了新功能？→ 他们的提交仍在，只是被 revert 抵消了错误部分，不会丢失
• CI/CD 流水线已基于错误合并触发构建？→ 下次构建会基于 revert 后的状态，问题自然消失

revert 合并时出现冲突怎么处理

冲突不是异常，而是 Git 在告诉你：“你当初合并时解决过的差异，现在要反向应用，但当前代码结构已经变了”。和普通 merge 冲突一样处理，但目标相反：你要让文件内容回到合并前的样子。

• 手动编辑冲突文件，删掉被错误合并进来的代码块（比如整个新组件、某段配置注入逻辑）
• 或用 git checkout --ours <file></file> 强制保留当前版本（即主干原有内容），适用于想彻底丢弃被合并分支所有改动
• 解决完后 git add <file></file>，再 git revert --continue
• 不想继续？git revert --abort 可中止，一切回退到 revert 前状态

撤销 revert 本身：如何重新启用曾被 revert 的分支

执行过 git revert -m 1 <merge-hash></merge-hash> 后，如果确认那个 feature 其实可以合，别删分支、别重试 merge，直接 revert 那个 revert 提交就行。

先找 revert 提交：git log --grep="revert" --oneline，通常信息类似 abcd123 revert "merge branch 'feature/login' into main"。然后：

• git revert abcd123 → 会新建一个提交，把之前 revert 的反向操作再反向一次
• 这个过程可能再次冲突（因为代码又变了），按上一节方式处理
• 完成后 push，所有人拉取后，feature 的变更就“复活”了，且历史清晰可溯：merge → revert → revert-of-revert

真正容易被忽略的是：revert 不是删除，而是一次明确的协作信号。团队里谁都能看到“这里曾出过问题，我们用什么方式修复”，而不是面对一段突然消失的历史干瞪眼。