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 已推送、分支已清理。这三个动作缺一不可，且没有“下次补上”的余地。
