怎么选分支模型
分支模型没有通用最优解，关键看三个约束：交付节奏、需要并行维护的版本数、回滚与审计要求。持续部署的团队适合轻量模型；要定期发版、且同时维护几个版本时适合发布分支；只有严格版本化交付、发布节奏固定的场景才需要 GitFlow 这类完整模型。选择时先看自己的约束，而不是照搬别人的仓库画一遍。
基本信息
| 持续部署 | 主干开发或 GitHub Flow 类轻量模型 |
|---|---|
| 定期版本发布 | 发布分支模型（常与主干开发组合） |
| 严格版本化交付 | GitFlow 类模型或发布列车 |
| 评估维度 | 交付节奏、并行版本数、回滚要求、审计要求 |
| 演进方式 | 从简单模型起步，按实际痛点加规则 |
典型使用场景
- 新团队建仓时确定分支策略与保护规则
- 团队从定期发版转向持续部署，重新评估分支数量
- 产品需要长期维护多个历史版本，规划发布与维护分支
- 合规或审计要求下，设计审批与留痕方式
- 两个团队合并时，找一套双方都能执行的折中方案
决策速记
决策速记
# 交付节奏快、回滚容易 → 从轻量模型起步
# 需要并行维护多个版本 → 发布分支 + 明确的支持窗口
# 审计合规要求高 → 保护规则 + 审批记录配套
# 团队经验有限 → 先把一条主线跑通，再逐步加规则模型对照
| 模型 | 并行版本 | 适用情形 |
|---|---|---|
| 主干开发 | 少 | 持续部署，功能未完用开关控制上线 |
| GitHub Flow 类 | 少 | 短分支加评审，随时可发布 |
| 发布分支模型 | 中 | 需要同时维护若干版本 |
| GitFlow 类 | 多 | 版本化交付且发布节奏固定 |
模型是手段，稳定交付才是目标。先从简单模型跑通，再按出现的问题增加规则，比一次性照搬复杂流程更容易落地。
换模型不只是改分支命名：保护规则、评审要求、流水线触发条件都要跟着调整，否则新旧流程长期并存会拖慢协作。