release分支应在满足全部条件时创建，存活不超过3–5天，仅允许修复P0/P1级bug、更新文档和构建配置，必须双目标合并至master和develop并立即删除，否则将导致流程失控与隐性冲突。
release 分支不是用来长期存在的，它的存在周期严格限定在“准备发布”这一窗口期内——从切出到合并回 master 和 develop，通常不超过 3–5 天。
如果你发现团队里有 release/v1.2.0 分支存活超过一周、还在持续提交，那说明流程已经失控，不是分支问题，是协作节奏或质量卡点没跟上。
什么时候该创建 release 分支？
不是“功能写完了就切”，而是满足以下全部条件时才切：
-
develop分支已集成所有计划上线的功能，且通过了冒烟测试 - 当前没有阻塞性的
bug（即 P0/P1 级别未修复） - 测试团队确认可以进入 UAT 或预发布验证阶段
- 版本号已确定（如
v1.2.0），且不打算再变更主版本号
常见错误是提前切分支，结果后面又往 develop 合并新功能，导致 release 分支和 develop 出现不可逆偏离。一旦切出，develop 就应冻结新增功能，只允许合入 hotfix 或已批准的紧急补丁。
release 分支上能做什么、不能做什么？
能做的只有三类操作：
- 修复测试中发现的 P0/P1 级 bug（必须同步提 PR 到
develop） - 更新文档、changelog、版本号字符串（如
package.json中的version） - 执行构建脚本、打环境配置标签（如
--env=prod）
不能做的包括：
- 新增功能逻辑（哪怕一行代码也不行）
- 重构已有模块（除非该重构是为修复某个已知 crash）
- 合并来自
feature的任何 PR（这类 PR 应退回develop重审）
很多团队踩坑在于把 release 当成“第二个 develop”，最后导致发布包里混入未充分测试的代码，或者 develop 因为没同步 release 的修复而回归出问题。
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
合并 release 分支时，为什么必须双目标？
它必须同时合并进 master 和 develop，缺一不可：
- 合入
master是为了打tag并部署生产 - 合入
develop是为了让后续开发能看到这次发布的全部修复和配置变更
漏掉后者最典型的现象是：下个 feature 分支基于旧版 develop 开发，结果上线后发现和刚发布的版本行为不一致——比如日期格式、API 超时时间、日志开关等配置项被覆盖。这不是代码 bug，是分支状态不同步导致的隐性冲突。
发布完成后，release 分支要不要删？
要删，而且应该立刻删。
- 保留只会增加
git branch -a输出噪音，干扰新人判断当前活跃分支 - 误操作风险高：有人可能基于残留的
release分支继续开发，再 push 上去就污染历史 - CI/CD 工具（如 Jenkins、GitLab CI）可能因监听
release/*模式而触发重复构建
删之前确认两件事：master 已打 tag（如 v1.2.0），且该 tag 已被 CI 部署成功；develop 已完成 merge 并通过基础 lint 和单元测试。删的动作本身用 git push origin --delete release/v1.2.0 即可，不需要本地 checkout。
真正难的不是操作，而是守住“只修 bug、不加功能、不拖时间”这三条线。一旦某次发布破例，下次就会更松，直到 release 分支变成没人敢动的黑箱。
