hotfix分支的典型使用场景
你正坐在办公室，手里的咖啡还没凉，测试组突然发来消息：线上版本有个严重 bug，用户无法登录，必须马上修复。这个时候，你不会去动正在开发的新功能分支，也不会直接在主分支上改代码。你会做什么？答案是：拉一个 hotfix 分支。
hotfix 分支的核心用途很明确——快速修复生产环境中的紧急问题。它不是用来开发新功能的，也不是日常提交的中转站，而是专为“救火”而生。
线上出问题，但新功能还在开发中
想象一下，你的主分支（main 或 master）已经发布了 v1.2 版本上线运行，而团队正在 dev 分支上开发 v1.3 的新特性。这时候发现 v1.2 有个安全漏洞，必须立刻修复并发布补丁版本 v1.2.1。
如果直接在 main 上改，容易把未完成的功能代码混进去；如果在 dev 上修，又可能带入不稳定代码。正确做法是从 main 分支切出一个 hotfix/v1.2.1 分支，在这里专注修复问题。
git checkout main
git checkout -b hotfix/v1.2.1修复完成后，把这个分支同时合并回 main 和 dev，确保补丁进入主干，也避免未来开发遗漏这个修复。
发布时间紧，流程不能乱
有些团队规定，所有上线代码必须走 PR（Pull Request）。即使情况紧急，也不能跳过审查。hotfix 分支在这种流程里反而更高效：你可以基于它发起一个高优先级的合并请求，让同事快速评审，既保证质量又不耽误时间。
更重要的是，hotfix 分支自带语义化命名。别人一看就知道这是紧急修复，不是某个半途而废的功能实验。日志清晰，责任明确，排查历史变更时也更容易定位。
什么时候不该用 hotfix？
如果你只是在本地修了个小 typo，还没影响上线服务，没必要拉 hotfix。日常迭代中的 bug 修复走正常的 feature 或 bugfix 流程就行。只有当问题直接影响了生产环境，且需要立即发布补丁时，才动用 hotfix 分支。
另外，长期维护多个版本的项目会更依赖 hotfix。比如你同时支持 v1 和 v2 两个大版本，某个共通缺陷需要分别打补丁，就可以从对应标签拉出 hotfix/v1.5.1 和 hotfix/v2.3.1，独立处理，互不干扰。