分支策略是什么
分支策略决定团队如何在版本控制系统中组织代码线：GitFlow 适合版本化发布与多版本并行维护，GitHub Flow 简单直接适合持续部署的服务，主干开发配合特性开关适合高频交付且自动化成熟的团队。选择的依据是发布节奏、是否需要维护多个版本、以及自动化测试的成熟度，而不是流行度。
基本信息
| GitFlow | 主干 + develop + 特性/发布/热修分支 |
|---|---|
| GitHub Flow | 主干 + 短特性分支 + 合并请求 |
| 主干开发 | 短命分支或直接提交主干 + 特性开关 |
| 决策依据 | 发布频率、多版本维护需求、自动化成熟度 |
| 核心代价 | 分支越多越长，集成越晚，冲突成本越高 |
典型使用场景
- 对外发行的软件需要同时维护多个历史版本，需要发布分支
- 纯在线服务持续部署，希望每次合并都能上生产
- 团队自动化测试成熟，可以把集成频率提高到每天多次
- 合规要求发布前需要冻结与审批，需要发布候选分支
- 多团队协作同一代码库，需要明确分支生命周期与归属
策略对比
| 策略 | 结构 | 适用 |
|---|---|---|
| GitFlow | 主干 + develop + 特性/发布/热修分支 | 固定版本、多版本并行维护 |
| GitHub Flow | 主干 + 短特性分支 + 合并请求 | 持续部署的在线服务 |
| 主干开发 | 短命分支或直接主干 + 开关 | 高频交付、自动化成熟 |
选择提示
选择提示
# 三个问题基本能定位策略方向
问三个问题：发布频率？是否维护多个版本？自动化测试成熟度？
# 分支生命周期越长，合并冲突与集成风险越高
分支越复杂，集成越晚，冲突成本越高
# 策略要配套约束，否则形同摆设
配套约束：合并请求必须过门禁、分支存活上限、定期清理同一组织不必统一到一种策略：对外发行的产品与内部在线服务可以并存不同策略，但要明确各自的分支命名与合并规则，避免互相模仿造成混乱。