紧急修复流是什么
线上故障需要绕过常规节奏时的受控流程：从已发布版本的 tag/分支拉修复分支，最小改动、跑必要门禁、快速发布并回合主干。流程可以加速——走审批加急、并行验证，但验证与记录不能取消；每个例外都要在事后补齐。能不能热修取决于两点：故障根因是否清楚、修复面是否隔离，而不是取决于催促的力度。
基本信息
| 起点 | 已发布版本的 tag/分支 |
|---|---|
| 改动范围 | 只含修复必需内容 |
| 门禁 | 测试与扫描可以裁剪范围，不跳过 |
| 收尾 | 回合主干并补记变更记录 |
常规与热修对比
| 维度 | 常规发布 | 热修 |
|---|---|---|
| 分支起点 | 主干最新 | 已发布版本 tag |
| 改动范围 | 当批全部变更 | 仅修复必需 |
| 验证 | 完整门禁 | 裁剪范围但不跳过 |
| 回合方式 | 自然合并 | cherry-pick 回主干 |
典型使用场景
- 线上 P1/P2 故障：根因明确、修复面清晰时走热修
- 版本冻结期：大版本临近发布但线上问题等不起，单独出热修
- 安全补丁：依赖漏洞需要立即出补丁版本
- 回滚不可行时：数据或兼容原因不能直接回滚，只能向前修
- 客户端兼容修复：已发版客户端触发的服务端问题
- 跨版本兼容：热修要同时兼容当前生产的数据结构与在用的客户端版本
- 定期演练：模拟热修全流程，暴露审批与权限瓶颈并按结果优化
热修流程
热修流程
# 从已发布 tag 拉修复分支
git switch -c hotfix/1.9.1 v1.9.0
# 最小修复并提交，只动必需文件
git commit -m "fix: 结算金额取整"
# 打 tag 触发发布流水线
git tag v1.9.1 && git push origin v1.9.1
# 回合主干，避免下个版本丢掉修复
git switch main && git cherry-pick <fix-commit>热修流程的每个例外都要在事后补齐：加速的是等待时间，不是评审与验证本身。
热修与常规版本会车：发版前核对两者是否包含对方变更，避免后发版本把已上线的修复覆盖掉。
热修通道要有专属审批与权限：走捷径不等于绕过审计，每次热修都留下可追溯记录。