hotfix分支是生产紧急修复的强制标准化流程：必须从main/master拉取，修复后同步合入main和develop，并打语义化tag；跳过该流程会导致修复不可追溯、测试缺失、develop漏补丁及tag与代码不一致。
hotfix 分支不是“可选流程”，而是生产环境出问题时必须走的标准化通道——它直接从 main（或 master）拉取，修复后必须同时合入 main 和 develop，否则开发分支会漏掉关键修复。
为什么不能直接在 main 上改然后 push？
因为 main 通常设为保护分支，禁止直接推送；更重要的是，跳过分支流程会导致：
• 修复无法被 Code Review 追溯
• 没有独立测试环境验证修复效果
• develop 分支长期缺失该补丁，下次发版可能重新引入相同 Bug
• Tag 版本与实际线上代码不一致（Tag 应该基于含 hotfix 的 main 提交）
git-flow-hotfix 命令 vs 手动创建分支的区别
git-flow-hotfix 是 Git Flow AVH 工具链提供的封装命令，它自动完成命名、合并、Tag 打标和清理，但依赖项目已初始化 git flow init 且配置了 hotfix 前缀（如 hotfix/）。手动操作更可控，适合未接入工具链或需定制流程的团队：
-
git checkout -b hotfix/login-null-pointer origin/main—— 显式指定远程main，避免本地main落后 -
git commit -m "fix: prevent NPE in user login"—— 提交信息必须含fix:，否则 CI 可能跳过构建或无法生成 changelog - Tag 名必须匹配语义化版本（如
v1.2.3），不能写成hotfix-123或fix-v1.2.3
合并 hotfix 到 develop 时最常踩的坑
很多团队只合入 main 就结束，忘了 develop。结果是：下个 release 分支从旧 develop 切出，Bug 又回来了。
- 必须先
git checkout develop，再git merge --no-ff hotfix/login-null-pointer - 如果
develop有大量新提交，merge 可能冲突——这时不能跳过，得人工确认修复逻辑是否仍适用 - 某些团队用
git cherry-pick替代 merge，但容易漏掉多提交修复，且破坏提交线性历史，不推荐
VSCode 里做 hotfix 的实际操作要点
VSCode 的 Git 面板能加速操作，但默认不显示 hotfix 相关动作，需手动触发：
- 点击底部状态栏分支名 → “Create New Branch” → 输入
hotfix/xxx→ 选择origin/main作为 base - 修复完成后，在源代码右键 → “Git: Stage Changes”，提交时务必检查消息格式
- 合并前先右键
main分支 → “Merge Into Current Branch”，再对develop重复一次 - 冲突文件会高亮显示，VSCode 的三栏对比中，“Current Change”是 hotfix 修改，“Incoming Change”是目标分支内容，别无脑选“Accept Incoming”
hotfix？比如一个仅影响灰度用户的小样式错位，走常规 PR 更稳妥；而支付失败、数据丢失类问题，才值得立即拉 hotfix 并中断当前发布节奏。
