回滚要分两层看
代码层用 git revert 生成一条反向提交把改动撤掉，部署层则把运行版本退回到上一个发布制品。两层解决的不是同一个问题：代码回退了，已经执行过的数据库结构变更不会自己退回来。所以回滚策略必须先写清触发条件与决策人，否则真出事时现场还得先开会讨论要不要回滚。
基本信息
| 代码层 | git revert 生成反向提交；撤销合并提交用 -m 指定主线父提交 |
|---|---|
| 部署层 | 回退到上一个发布制品 |
| 前置条件 | 明确触发阈值与决策人 |
| 数据变更 | 需要单独设计回滚或前向修复方案 |
| 能力验证 | 定期做回滚演练 |
典型使用场景
- 上线后核心指标异常，先回退版本止损，再从容排查原因
- 单个功能引发线上问题，只撤销那一个提交而不影响其他已发布内容
- 误合并了未完成的功能分支，用撤销合并提交的方式恢复
- 配置类改动需要快速恢复上一版本
- 事故复盘中验证回滚路径是否真的可用
常用示例
常用示例
git revert <问题提交> # 生成反向提交，不改写历史
git revert -m 1 <合并提交> # 撤销合并提交，-m 1 保留主线一侧
git log --oneline -5 # 确认反向提交已经生成
git push origin main # 推送反向提交，触发正常发布流程
git revert --no-commit <提交> # 先只落改动，便于人工确认后再提交两层回滚对照
| 层面 | 手段 | 注意事项 |
|---|---|---|
| 代码层 | 反向提交 | 保留历史，公共分支首选 |
| 代码层 | 重置分支指针 | 仅限尚未推送的私有分支 |
| 部署层 | 回退到上一制品 | 依赖制品仓库保留旧版本 |
| 数据层 | 迁移脚本或前向修复 | 代码回退撤销不了已执行的结构变更 |
回滚演练与真实回滚同样重要：没演练过的路径不能算作回滚能力，等到出事时才第一次走这条路往往来不及。
公共分支上不要用重置历史的方式回滚，那会让所有人的本地分支与远端分叉；撤销已经推送的改动应使用反向提交。