热修复必须从master分支拉取hotfix分支，而非release分支，因master是线上真实版本唯一可信源；修复后须同步合并至develop及当前release分支，避免未发布功能混入生产或修复丢失。

不能直接基于 release 分支做热修复——这是多数团队踩坑的起点。正确做法是：热修复必须从 master（或 main）分支拉出 hotfix/*，而不是从 release/* 分支拉。

为什么 hotfix 必须从 master 而不是 release 拉？

因为 master 是线上真实运行版本的唯一可信源。即使 release 分支已合入部分新功能但尚未上线，它的 HEAD 并不等于生产环境代码。若从 release 拉 hotfix，修复后合并回 master 会把未发布功能一并带入生产，造成不可控变更。

• master 上的最新 tag（如 v1.2.0）才是当前线上版本快照
• release/* 是“即将上线”的候选，可能含未验证逻辑、配置差异或待删调试代码
• GitFlow 规范明确要求 hotfix 的基线是 master，不是 release

如果 bug 确实只在 release 分支暴露怎么办？

这种情况本质是预发布验证问题，不是线上热修复场景。应走 release 分支修复流程，而非 hotfix：

Cnb Cool Git

CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。

下载

• 确认该 bug 是否已在生产环境复现 —— 若未复现，就不属于 hotfix 范畴
• 在 release/* 分支上直接提交修复（前提是该分支允许提交，且有 CI 验证机制）
• 修复后重新触发 UAT 流程，通过后再合并到 master 和 develop
• 若团队禁用 release 直接提交，则需将问题降级为 feature 或 bugfix 提交到 develop，等下个 release 周期

hotfix 合并时最容易漏掉的一步

合并完 hotfix 到 master 后，必须同步合并到 develop（或 main 对应的集成分支），否则下次发版会丢失该修复。很多人只记得打 tag 和推 master，却忘了这步：

git checkout develop<br>git pull origin develop<br>git merge --no-ff hotfix/login-error -m "merge: apply login fix to develop"

更关键的是：如果团队使用 release/* 分支做预发布，还要确保该 hotfix 已 cherry-pick 或 rebase 进当前活跃的 release/* 分支，否则 UAT 环境仍跑着旧逻辑。

真正紧急的线上修复，从来不是比谁敲命令快，而是比谁清楚当前哪个 commit 对应线上真实状态、哪个分支能安全承载修复、以及修复后是否被所有下游分支感知到。