git中develop与release分支数量无固定比例，由交付节奏决定；release分支应短命、带明确版本号、仅修缺陷、及时删除，develop须稳定可随时发布。
Git 中没有“最佳配比”这种固定比例关系——develop 和 release/* 分支的数量关系，完全由交付节奏决定，不是数学题，而是协作节奏的映射。
release 分支不该长期存在，只在发布窗口期临时创建
很多人误以为 release/* 是常驻分支，像 develop 一样一直开着。实际它只是个“发布快照”，生命周期极短：从 develop 切出 → 测试/修 bug → 合并到 main 和 develop → 删除。如果一个 release/1.2.0 分支存活超过 5 天，大概率说明测试卡点、需求返工或流程阻塞。
- 发布分支命名必须带明确版本号，如
release/v1.2.0，不能用release/staging这类模糊名 - 禁止在
release/*上新增功能逻辑，只允许修复测试发现的缺陷 - 每次合并回
develop前，必须确认所有 hotfix 已同步（否则develop会漏掉线上已修复的问题）
develop 分支必须保持“随时可切 release”状态
develop 不是“功能堆砌区”，而是下一次发布的基线。它的稳定性直接决定能否按计划创建 release/*。常见反模式是：功能 A 卡在 PR 审核、功能 B 本地调试未推、功能 C 的 CI 持续失败——此时 develop 已不可发布，却还在往里合代码。
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
- 每天至少一次从
main向develop合并 hotfix（可用脚本自动完成） - 每个
feature/*合入前，CI 必须通过全部单元 + 接口测试，且无编译警告 - 如果
develop连续 3 天无法通过全量构建，应暂停新功能合并，优先清理阻塞项
当 release 分支数量 > develop 分支数量时，说明流程已失控
正常情况：develop 永远只有 1 个；release/* 在任意时刻最多 1 个（多版本并行维护除外）。若看到 release/v1.1.0、release/v1.2.0、release/v1.3.0 同时存在，基本意味着：
- 团队在用 release 分支代替 feature 分支做开发（错误复用）
- 发布流程未闭环：上一个 release 未合入
main就急着开下一个 - 缺乏版本冻结机制，导致多个 release 分支互相污染（比如共用同一套配置或数据库迁移脚本）
真正需要多 release/* 并存的场景极少，仅限于同时维护 v1.x（LTS）、v2.x（最新版）两个主干线，且必须有独立的 develop-v1 和 develop-v2 支撑。
最易被忽略的一点：发布分支的消亡比创建更重要。很多团队记得切 release/*，却忘了删——残留的 release/* 会干扰自动化脚本识别当前发布目标，也会让新成员误以为那是“正在开发的分支”。
