git revert 不删除任何历史，而是新建一个内容相反的提交来抵消指定提交的改动。正因为不改历史，它是已经 push 给团队之后唯一稳妥的撤销方式。
本文列出 git revert 的常用参数，包括撤销合并提交时必须用的 -m，以及冲突时的续作命令。
关于本系列
本文是《Git 使用教程》按命令拆分的第 14 / 28 篇，全部收录在 Git 栏目。参数表列的是日常高频项，并非穷举；想看某个命令的完整参数，用
git revert -h 看精简列表、git help revert 看完整手册。示例以 Git 2.56.0 为准。一、命令语法
先看语法骨架，再对照下一节的参数表。<占位> 表示必填值，实际输入时不要带尖括号；[...] 表示可选项，-- 用来分隔选项与路径。
bash语法
git revert [<options>] <commit>...二、参数逐项详解
下表按用途列出 git revert 的常用参数，每项都注明了「它到底改变了什么」。
| 参数 | 作用 |
|---|---|
<commit>... | 要抵消的一个或多个提交；默认按给定顺序逐个生成反向提交 |
-n / --no-commit | 只把反向改动应用到工作区与索引，不自动生成提交，便于攒成一次提交 |
--no-edit | 沿用自动生成的 revert 信息，不打开编辑器 |
-m <n> / --mainline=<n> | 撤销合并提交时指定保留第几个父提交为主线（通常是 1） |
-e / --edit | 提交前打开编辑器修改信息（默认行为） |
-s / --signoff | 追加 Signed-off-by 行 |
--continue | 解决冲突并 add 之后继续完成 revert |
--abort | 放弃整个 revert 序列，回到操作前状态 |
--skip | 跳过当前提交，继续处理后面的 |
--quit | 退出 revert 序列但保留已经完成的改动与提交 |
--strategy=<策略> | 指定合并策略，一般不用手动改 |
reset 与 revert 怎么选
| 场景 | 用哪个 |
|---|---|
| 提交只在自己本地、还没 push | git reset，历史保持干净 |
| 提交已 push，别人可能拉取过 | git revert，不改历史 |
| 要撤销的是一个合并提交 | git revert -m 1 <merge-commit> |
三、常用示例
撤销一次已公开的提交
bash撤销一次已公开的提交
git log --oneline -5 # 找到要撤的哈希
git revert a1b2c3d
git push origin main攒成一次提交
bash攒成一次提交
git revert -n a1b2c3d
git revert -n b2c3d4e
git diff --cached --stat
git commit -m "revert: 回退上一批有问题的改动"撤销合并提交与冲突处理
bash撤销合并提交与冲突处理
git revert -m 1 --no-edit f9e8d7c
# 若出现冲突
git status -s
git add <冲突文件>
git revert --continue
# 或整段放弃
git revert --abort四、注意事项
-m 1 的含义要想清楚
合并提交有多个父提交，
revert 必须知道「以哪一边为主线」才能算反向 diff。-m 1 通常指合并时的当前分支。另外，revert 掉一个合并提交后，Git 会认为那段历史已经被抵消，日后想重新合并同一分支需要先 revert 掉这次 revert。revert 本身也是一次普通提交： 它有哈希、有作者、能 push、也能被再次 revert。所以「回滚上线失败」最稳的姿势就是
git revert + 正常流程推上去，所有人的历史都保持线性。五、小结
git revert 的参数不多，核心就三条：-n 攒批、-m 处理合并提交、--continue/--abort 处理冲突。它用「多一次提交」换取「历史不被改写」，在协作场景里几乎总是更划算的选择。
本系列共 28 篇，一个命令一篇，完整目录见 Git 栏目。下一篇：git clean 命令参数详解。