热修复分支是什么
线上紧急修复的专用通道：从发布标签切出补丁分支，只做必要改动，走加急评审，打补丁标签发布，最后把修复回流到主干。它与常规分支的关键差别在于起点是发布标签，而不是主干末端。
基本信息
| 起点 | 线上正在运行的发布标签，例如 v1.2.0 |
|---|---|
| 要求 | 改动最小、测试聚焦、流程加急但保留记录 |
| 版本号 | 补丁位递增，例如 v1.2.0 之后是 v1.2.1 |
| 回流 | 把修复合回主干，避免下个版本重新出现同一缺陷 |
| 发布 | 打补丁标签并由标签触发发布流水线，产物与标签对应 |
典型使用场景
- 线上出现阻塞业务的缺陷，需要立即修复
- 出现安全漏洞，需要紧急发布补丁版本
- 数据计算或展示错误需要快速纠正
- 文案与配置类紧急变更，无法等到例行版本
- 中等严重但不宜拖到下个版本的问题
常用示例
常用示例
git switch -c hotfix/1.2.1 v1.2.0 # 从发布标签切出补丁分支
git commit -m 'fix: 修正空会话导致的崩溃' # 只改修复必需的文件
git push -u origin hotfix/1.2.1 # 推送并触发加急评审
git tag -a v1.2.1 -m 'hotfix 1.2.1' # 打补丁标签
git push origin v1.2.1 # 推送标签触发发布
git switch main && git cherry-pick <修复提交> # 把修复回流到主干步骤与要点
| 步骤 | 要点 |
|---|---|
| 切分支 | 从发布标签切出，不要从主干末端切 |
| 控制改动 | 只改修复必需的文件，不带入未完成功能 |
| 评审 | 加急通道要有边界，事后补齐评审记录 |
| 回流 | 修复合回主干，并补一条回归用例 |
热修复完成后按流程复盘根因并补齐回归测试，减少同类问题再次发生，这一步常被故障后的放松心态跳过。
补丁分支的改动范围越小越好：混入其他改动会扩大验证范围，直接延长故障恢复时间。
补丁发布后要把版本号、修复内容与影响范围写进发布说明并同步给值班同事，避免下一次同类问题重复排查。