必须指定 -m 1，因为合并提交有两个父节点，Git 无法自动判断以哪个为基准生成反向变更；-m 1 表示保留第一个父提交（主分支）代码，撤销被合并分支的全部更改。
git revert -m 1 为什么必须指定，不加会报错
直接运行 git revert <merge-commit-hash> 会失败，报错类似 error: commit <hash> is a merge but no -m option was specified。Git 不知道该以哪个父提交为“基准”来生成反向变更——合并提交有两个父节点，它没法猜你想要保留哪条线的逻辑。
绝大多数误合并场景下（比如把 feature/payment 错合进 main），你要保留的是 main 当前状态，也就是第一个父提交（即合并前 main 的 HEAD）。所以必须加 -m 1。
-
-m 1：撤销被合并分支引入的所有变更，主干代码不变 -
-m 2：反过来，保留被合并分支的代码，丢弃主干后续修改（极少用，慎用） - 不确定时先查：运行
git show --pretty=raw <merge-commit-hash>，看Merge:行两个哈希谁在前——前面那个就是-m 1对应的父提交
已推送的合并被多人拉取后还能安全 revert 吗
能，而且这正是 git revert 的核心价值所在。只要没人对那个错误合并之后的 main 做过强制推送（push --force），就完全安全。
revert 本质是新增一个提交，不改任何已有 commit 的 SHA-1。所有协作者下次执行 git pull，都会自动拿到这个新提交，历史线性增长，无冲突、无重写、无需协调。
- 别人本地已有该 merge 提交？→ 拉取后自动包含 revert，效果立即生效
- 别人已在该 merge 后提交了新功能？→ 他们的提交仍在，只是被 revert 抵消了错误部分，不会丢失
- CI/CD 流水线已基于错误合并触发构建？→ 下次构建会基于 revert 后的状态，问题自然消失
revert 合并时出现冲突怎么处理
冲突不是异常，而是 Git 在告诉你：“你当初合并时解决过的差异，现在要反向应用，但当前代码结构已经变了”。和普通 merge 冲突一样处理，但目标相反：你要让文件内容回到合并前的样子。
- 手动编辑冲突文件，删掉被错误合并进来的代码块（比如整个新组件、某段配置注入逻辑）
- 或用
git checkout --ours <file>强制保留当前版本（即主干原有内容），适用于想彻底丢弃被合并分支所有改动 - 解决完后
git add <file>，再git revert --continue - 不想继续？
git revert --abort可中止，一切回退到 revert 前状态
撤销 revert 本身：如何重新启用曾被 revert 的分支
执行过 git revert -m 1 <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 不是删除，而是一次明确的协作信号。团队里谁都能看到“这里曾出过问题，我们用什么方式修复”，而不是面对一段突然消失的历史干瞪眼。
