短生命周期分支是什么
短生命周期分支的做法是让每条分支只对应一个可评审的小任务，尽快合回主线。分支存活时间越短，与主线的偏离越小，合并时的冲突面与集成风险也就越低。它依赖两个配套习惯：先把分支切得足够小，再定期同步主线。这套思路属于主干开发与 GitHub Flow 的共同基础，与具体托管平台无关，但在持续部署的团队里收益最明显。
基本信息
| 原则 | 一个分支对应一个可评审的小任务 |
|---|---|
| 同步 | 评审前或每日同步主线 |
| 收敛 | 合并后立即删除分支 |
| 度量 | 观察分支存活时长与单次变更规模 |
| 平台 | 任意 Git 客户端与托管平台 |
典型使用场景
- 功能可以分层交付时，按层次切成多个小分支
- 修复线上缺陷，单独开一条短分支快速合入
- 重构与行为改动分开提交，降低评审难度
- 新功能用特性开关隔离，代码先合入再逐步放开
- 团队冲突频繁时，用缩短分支寿命来治理
- 新人上手阶段，用小任务快速形成提交与评审节奏
小步流程示例
小步流程示例
git switch main && git pull --ff-only # 先同步主线
git switch -c fix/231-retry # 按任务编号命名
git commit -m 'fix: retry once on 502' # 单一职责的提交
git push -u origin fix/231-retry # 推送并建立跟踪
# 发起评审，合入后立即删除分支分支长短的代价对比
| 维度 | 短分支 | 长分支 |
|---|---|---|
| 与主线偏离 | 小，冲突少 | 大，合并困难 |
| 评审难度 | 单次范围清晰 | 一次改动量大 |
| 回滚成本 | 低 | 高 |
把「分支存活时长」纳入团队观察指标，冲突治理的效果远好于事后补救。
小步交付依赖可独立验证：每个小分支合入后主线都应保持可构建、可部署，做不到时先改善测试与开关能力。