git revert 回退是什么
以新增提交抵消问题变更：git revert 生成反向提交，历史保留、可审计，适合已推送的共享分支。支持单个提交、提交区间与合并提交回退；合并提交要用 -m 指定保留哪一侧主线。生产事故里的快速回退通常就是 revert 加发布流水线，回退动作与普通变更一样走验证。
基本信息
| 命令 | git revert <commit>；合并提交需 -m 指定主线 |
|---|---|
| 特点 | 不改写历史，适合共享分支 |
| 与 reset 的区别 | reset 改写历史，只应用于私有分支 |
| 流程建议 | revert 后走 CI 验证与正常发布流程 |
| 区间回退 | git revert <old>..<new> 批量回退连续提交 |
典型使用场景
- 生产事故：快速抵消问题提交并走发布流程
- 无法热修的发布：先 revert 恢复服务，再从容修复
- 区间撤销：一次性回退某功能带来的若干提交
- 审计留痕：替代 reset，保留完整历史与原因
- 冲突处理：revert 冲突按原变更意图逐处解决
- 并行推进：revert 先恢复服务，修复分支随后再合并回来
- 留痕规范：revert 提交信息写清事故单号与影响范围
revert 常用姿势
revert 常用姿势
git revert --no-edit abc1234
# 合并提交：-m 1 表示保留第 1 父提交一侧
git revert -m 1 --no-edit 9f2c1ab
# 区间回退：回退 A 之后到 B 的提交
git revert --no-edit A..B
git push origin main回退手段对比
| 手段 | 历史 | 适用场景 |
|---|---|---|
| revert | 新增抵消提交，历史保留 | 共享分支与已发布内容 |
| reset --hard | 改写历史 | 本地未推送的私有分支 |
| 手工恢复再提交 | 人工恢复文件 | 少量文件且 revert 冲突多时 |
revert 一个合并提交后，被合并分支再次合并时相关内容可能不再进入：需要了解 revert-a-merge 的后续影响。
冲突多是「别人改过同一处」：按抵消原变更的目标逐处判断，不要照抄原文。
大范围回退冲突可能成片：先评估提交依赖顺序，必要时逐提交回退而不是一次区间回退。
revert 同样改变生产行为，也要走评审与记录，紧急通道别省这一步。