Git临时修复线上紧急Bug的分支切换艺术

线上出紧急Bug时，直接切换到main分支改完就推——这个操作看着省事，但其实后患无穷。为什么呢？因为这样会污染主干历史，后续根本看不出哪次部署引入了这次修复，而且CI/CD流水线也可能被未测试的提交带歪。所以常规做法是：从出问题的版本拉出独立的hotfix分支来隔离修复，再通过cherry-pick同步到开发主线，最后用--no-ff合并回main并打好新tag，收尾清理分支。这样历史清晰、流程可控。

紧急修复时为什么不能直接在 main 上改

线上出问题，你第一反应可能是切到main分支改完立刻push——但这样会污染主干历史，且无法回溯这次hotfix是哪次部署引入的。Git的分支本质是轻量指针，main应该只承载经过验证的、可部署的代码。临时修复必须隔离，否则CI/CD流水线可能因未测试的提交触发异常构建。具体怎么操作？从出问题的tag或commit（比如v2.3.1）拉出新分支，命名用hotfix/xxx格式，例如git checkout -b hotfix/login-500 v2.3.1。修复后立即commit，消息带fix:前缀和issue编号，如fix: login 500 error (#427)。不要合并回main，先推送到远端：git push origin hotfix/login-500。

如何让 hotfix 同时生效于线上和开发主线

hotfix不止要上线，还得合入后续开发分支（比如develop），否则下次发版又会复现。但这里有个陷阱：不能直接git merge hotfix/xxx到develop，因为hotfix基于旧版本，直接合并会把develop里已有的改动也带进来，造成冲突或重复变更。正确做法是只取修复commit，不带分支上下文。先查出hotfix的修复commit hash：git log --oneline hotfix/login-500；切到develop，执行：git cherry-pick ；如果冲突，手动解决后git add . && git cherry-pick --continue；再推送到远端：git push origin develop。

修复上线后怎么安全合并回 main 并打新 tag

hotfix分支本身是临时产物，上线验证通过后，必须合入main并打新patch版本tag（如v2.3.2）。但注意：不能用fast-forward合并，否则main上看不到hotfix是一个独立逻辑单元。强制创建merge commit，保留上下文：git checkout main；git merge --no-ff hotfix/login-500（--no-ff是关键）；提交信息默认是Merge branch 'hotfix/login-500'，可编辑补充上线时间、影响范围；打tag：git tag -a v2.3.2 -m "fix: login 500 error, deployed 2024-06-12"；推送：git push origin main v2.3.2。

容易被忽略的清理与同步细节

很多人merge完就以为结束了，结果下次切分支发现hotfix还在本地，或者远端分支残留。更麻烦的是，CI系统可能误触发hotfix/*分支的构建任务。本地删分支：git branch -d hotfix/login-500；远端删分支：git push origin --delete hotfix/login-500；通知团队成员更新本地main和develop：git fetch --prune（--prune会自动清理已删除的远端跟踪分支）；检查CI配置是否exclude了hotfix/*分支，避免误构建。真正麻烦的不是操作步骤，而是忘记--no-ff或漏掉--prune——前者让历史不可追溯，后者导致本地分支列表越来越乱，直到某天git checkout hotfix/xxx成功却拉不到最新提交，才意识到远端早删了。