上线后的系统突然报错，用户无法下单，客服电话被打爆。这个时候，没人关心代码多优雅，唯一的目标是——赶紧修好。这就是紧急修复（Hotfix）的典型场景，而如何管理好紧急修复分支，直接决定了你能不能在最短时间内把系统拉回正轨。
什么时候该起一个紧急修复分支？
当生产环境出现严重缺陷，且不能等待下一个发布周期时，就必须拉出紧急修复分支。比如支付失败、数据展示错误、登录异常这类影响核心流程的问题。这时候还在主干上直接改？风险太大，容易带入其他未测试功能。
标准流程：从 master 拉分支，修完合并回去
紧急修复分支通常从 master 或当前生产环境对应的标签（tag）拉出，命名建议统一为 hotfix/ 开头，例如：
git checkout -b hotfix/user-login-fail master在这个分支上只做一件事：修复问题。不要顺手重构，也不要加新功能。改完后提交，推送到远程：
git add .
git commit -m "修复用户登录 token 验证失效"
git push origin hotfix/user-login-fail修复完成后怎么合入代码？
创建 Pull Request 或 Merge Request，目标是合并回 master 和 develop（或你的主开发分支）。为什么两个都合？因为 master 确保生产环境能立刻发布，develop 保证这个修复不会在下次迭代中被“重新引入”。
合完记得打个新 tag，比如 v1.2.1，方便运维同事部署：
git tag -a v1.2.1 -m "修复登录问题"
git push origin v1.2.1别忘了清理战场
修复上线后，本地和远程的 hotfix/ 分支就可以删了。留着只会增加分支列表的噪音：
git branch -d hotfix/user-login-fail
git push origin --delete hotfix/user-login-fail团队里有人习惯把所有紧急修复都堆在主干上直接改，短期看省事，长期看等于埋雷。一旦多人同时修改，代码冲突、误删逻辑、发布范围失控，问题只会更糟。
规范的分支管理不是为了流程而流程，是在高压下保持冷静的操作手册。就像消防预案，平时不起眼，真着火的时候，它能救场。