hotfix 分支必须从 master（或 main）创建，修复后须双向合并至 master 和 develop；命名需统一前缀 hotfix/ 且版本号对齐 latest tag；合并后立即打 annotated tag 并清理分支。

hotfix 分支必须从 master（或 main）创建，修复后必须同时合并回 master 和 develop —— 漏掉任一端都会导致线上问题反复出现。

hotfix 分支该从哪个分支切出来？

只能从 master（或 main）切。这是硬性前提，不是建议。

• 如果从 develop 切，修复内容会混入未验证的功能，破坏 master 的稳定性
• 如果从某个 feature 分支切，修复无法准确定位到对应生产版本，tag 会失真
• 执行命令必须是：git checkout master && git pull && git checkout -b hotfix/1.2.3（先确保本地 master 是最新状态）

为什么 hotfix 必须双向合并：master 和 develop？

单向合并（只合进 master）是高频线上复发 bug 的根源之一。

• master 合并是为了立即发布修复版本（打 tag、部署）
• develop 合并是为了让后续所有新功能都继承这个修复，否则下个版本上线时，bug 会“原地复活”
• 实际项目中，80% 的“修复后又出现”问题，都是因为漏了 git merge hotfix/1.2.3 到 develop
• 建议把合并 develop 这步写进 CI 流水线的 post-merge hook，或用 git-flow hotfix finish 1.2.3 自动完成双合并

hotfix 分支命名与 tag 规范直接影响发布追溯

命名不是为了好看，而是为了机器可解析、人能快速定位。

• 前缀必须统一，如 hotfix/，避免用 fix/ 或 bugfix/ —— 多数自动化脚本只识别标准前缀
• 版本号需与当前 master 的 latest tag 对齐，例如 master 最新 tag 是 v1.2.2，hotfix 就该叫 hotfix/1.2.3，不是 hotfix/1.2.2-patch1
• 合并到 master 后必须立刻打 tag：git tag -a v1.2.3 -m "hotfix: fix null pointer in payment callback"，tag 名和分支名保持一致
• 不要跳过 -a（annotated tag），轻量 tag（git tag v1.2.3）无法携带提交者、时间、注释，CI 发布时会拒绝识别

hotfix 合并后不清理分支会污染长期分支图谱

hotfix 是临时通道，不是长期存在分支。不删，下次 git branch --all 会看到一堆 hotfix/xxx，且容易误操作。

• 手动流程中，合并完成后必须执行：git branch -d hotfix/1.2.3（本地） + git push origin --delete hotfix/1.2.3（远程）
• 如果用 git-flow，git-flow hotfix finish 1.2.3 会自动删除本地和远程 hotfix 分支
• 注意：git branch -D（大写 D）是强制删除，可能丢未合并内容；务必确认已双合并成功再删
• 团队可配置 pre-push hook，禁止推送任何以 hotfix/ 开头的分支到远端 —— 强制要求 hotfix 只存在于本地或 CI 构建环境

真正难的不是操作步骤，而是每次热修复后，能否在 5 分钟内确认 develop 已同步、tag 已推送、分支已清理。这三个动作缺一不可，且没有“下次补上”的余地。