release/分支应在develop功能冻结、集成测试准入条件满足（如所有feature合并、CI通过、QA确认）且明确发布正式版本时创建；hotfix/分支仅在生产环境紧急故障且问题源于master当前版本时，从master拉取并优先处理，修复后必须同步至master和当前release分支。
release/* 分支什么时候该建？
当 develop 分支上的功能已冻结、进入集成测试阶段，且明确要发 v1.2.0 这样的正式版本时，才创建 release/1.2.0 分支。
它不是“功能做完就建”，而是“功能齐了 + 测试准入条件满足”之后的产物。比如：所有关联的 feature/* 已合并进 develop，CI 流水线通过，QA 签字确认可进入预发布环境。
- 错误做法：在
develop还没合完feature/login就提前建release/1.2.0，结果发现漏功能，又得往 release 分支里硬塞代码 —— 这破坏了 release 分支“只修 bug 不加功能”的原则 - 正确节奏：
git checkout -b release/1.2.0 develop→ 部署到预发环境 → 修复release/1.2.0上发现的 bug → 确认无误后合并到master并打v1.2.0Tag - 注意：
release/*分支生命周期很短，发版完成后必须删掉，否则会干扰下一轮发布（比如release/1.2.0和release/1.3.0同时存在，容易误操作）
hotfix/* 分支必须从 master 拉，不能从 develop
生产环境出严重问题（比如支付失败、用户无法登录），且 master 上当前最新提交就是出问题的版本，这时才触发 hotfix/* 流程。
关键判断点：修复必须立即上线，不能等下一个 release 周期；且问题根源在 master 当前状态，而不是 develop 里还没发布的代码。
- 错误做法：线上报错，但你直接从
develop拉分支改 —— 修复可能包含未测试的新功能，上线风险极高 - 正确做法：
git checkout -b hotfix/payment-fail master→ 修完测试通过 →git checkout master && git merge --no-ff hotfix/payment-fail→git tag v1.2.1→git checkout develop && git merge --no-ff hotfix/payment-fail - 漏掉这步会出事：合并回
develop必须紧接在合并到master之后做。如果跳过，下次release从develop拉，就会漏掉这个修复
release 和 hotfix 同时存在怎么办？
它们可以共存，但操作顺序不能乱：hotfix 优先级永远高于 release。
比如 release/1.2.0 正在预发测试，突然线上 master 的 v1.1.0 版本崩了，就得立刻切出 hotfix/v1.1.1。修完上线后，hotfix/v1.1.1 的改动也要同步进 release/1.2.0 分支（用 git cherry-pick 或重新 merge），否则新版本会重复出同样问题。
- 常见坑：hotfix 合并回
master后，忘记把 commit 也同步到当前release/*分支，导致发版时 bug 回归 - 别依赖自动同步：Git 不会自动把 hotfix 推到 release 分支，必须手动处理
- 如果 hotfix 影响面大（比如改了底层 SDK），建议暂停 release 分支的测试，先验证 hotfix 是否引入新冲突
为什么不用 bugfix/* 替代 hotfix/*？
bugfix/* 是开发阶段内部用的临时分支，用于修 develop 或 feature/* 里的问题；而 hotfix/* 是唯一能合法修改 master 的分支类型，有权限和流程约束。
- 权限差异：
hotfix/*通常只开放给运维或值班工程师，bugfix/*任何人都能建 - 命名即契约：
hotfix/xxx表示“此分支的输出必须生成新 Tag 并立即部署”，bugfix/xxx没这层语义 - CI/CD 区别：流水线会对
hotfix/*自动触发生产环境构建和灰度发布，bugfix/*只走开发环境流程
真正卡住团队的，往往不是分支怎么建，而是“谁来判断现在该建哪个分支”。release/<em></em> 和 hotfix/ 的触发条件写在文档里容易，落实到每天的站会上，需要明确的责任人和清晰的决策路径。
