撤销合并提交是什么
撤销一个合并提交必须指定保留哪个父提交：git revert -m 1 <合并提交> 表示以主干侧的父提交为基准生成一条反向提交。它在历史末端新增记录、不修改既有历史，是共享分支上撤销合并的安全做法。
基本信息
| 语法 | git revert -m <父编号> <合并提交> |
|---|---|
| 父编号含义 | 1 表示合并时的当前分支侧，2 表示被合并进来的分支侧 |
| 先确认顺序 | git show --no-patch --pretty=%P <合并提交> 查看两个父提交 |
| 后续影响 | 被撤销的分支再次合并时，Git 认为这些提交已经处理过 |
| 替代方案 | 尚未推送时可改用 git reset --hard，但会改写历史 |
典型使用场景
- 上线后发现刚合入的特性引发故障，需要快速回退
- 误把不该发布的分支合入主干，需要撤销
- 评审流程出错导致不合规的改动进入主干
- 需要保留历史审计线索，不能改写已有提交
- 故障处理中先恢复可用状态，之后再逐步排查根因
常用示例
常用示例
git show --no-patch --pretty=%P <merge_sha> # 查看两个父提交的顺序
git revert -m 1 <merge_sha> # 保留主干侧父提交的视角
git log --oneline -3 # 确认新增了反向提交
git push origin main # 推送撤销结果
git revert <revert_sha> # 需要重新合并该分支时，先撤销这次撤销
git merge <原分支> # 再执行一次合并即可带回内容父编号与结果对照
| 父编号 | 保留哪一侧 | 典型场景 |
|---|---|---|
| -m 1 | 合并时的当前分支（通常是主干） | 撤销刚合入主干的特性 |
| -m 2 | 被合并进来的分支一侧 | 撤销方向相反的合并 |
| 未指定 | 命令报错并要求给出 -m | 任何一次合并撤销 |
撤销合并不会让历史消失：原来的合并提交仍在，只是新增了一条把它的改动反做回去的提交，审计时可以看到完整来龙去脉。
被撤销的分支之后重新合并时，Git 认为这些提交已经处理过而不会带回内容；必须先把这次撤销再撤销，然后重新合并。