分支策略与分支生命周期

为什么团队需要明确的分支生命周期

稳定发布main

1.92.02.1

集成开发develop

D1D2D3D4

功能开发

F1F2

发布准备

R1R2

紧急修复

H1

很多团队最大的问题不是"不会建分支"，而是 真正影响团队质量的不是分支数量，而是这些问题有没有说清楚：

• 哪条分支是稳定基线
• 哪条分支承接日常开发
• 紧急修复从哪里切、修完回到哪里
• 发布后多维护线怎么同步

如果这些职责没有提前约定，Git 命令本身并不会替团队补上流程。

1. 先定义每类分支的职责

一个常见而且足够轻量的做法是把分支分成 4 类：

• 主线分支：代表当前稳定可集成状态
• 主题分支：承接单个功能或单个修复
• 发布分支：承接版本冻结、验收、发版准备
• 热修复分支：承接线上紧急问题

重点不是名字一定叫 main、release/*、hotfix/*，而是每类分支的职责和进入退出条件必须稳定。

2. 主题分支应该短命且单一

日常开发最稳的习惯仍然是：

git switch main
git pull --ff-only
git switch -c feature/account-audit-log

这样做的价值在于：

• 评审边界清楚
• 回滚边界清楚
• rebase 和 merge 的风险更小
• 被取消的工作可以整段丢弃

主题分支一旦开始承接两件以上事情，就会慢慢失去“可评审、可回滚、可发布”的价值。

3. 主线分支应该尽量保持可集成

不管团队偏 merge 还是 rebase，主线分支都最好满足一个最低标准：

• 新人拉下来就能继续开发
• CI 必须是可信的
• 不应该长期堆积“还没整理好但先放进去”的提交

也就是说，主线更像“团队可信基线”，而不是临时仓库。

4. 发布分支的意义不是“再复制一份 main”

发布分支最适合承担这些事：

• 版本冻结
• 最后阶段的回归验证
• 只接受低风险修复
• 记录这次发布的最终边界

它不适合继续承载大规模新功能。
一旦发版分支开始同时接受大功能和紧急修复，团队就会很难判断：

• 哪些改动该进当前版本
• 哪些改动应该留到下个版本

5. 热修复分支要最短路径闭环

线上故障处理时，分支策略最重要的不是优雅，而是闭环快：

1. 从稳定发布基线切出 hotfix 分支
2. 只修这一个紧急问题
3. 通过最小验证后尽快合并和发布
4. 再把同样的修复同步回主开发线

这样做能避免“线上修好了，但主线没带回去，过几天又丢”的问题。

6. 用例：多人并行开发时如何避免主线混乱

如果 3 个人同时做不同功能，更稳的结构是：

• 每人一个主题分支
• 主线只接纳通过 review 的分支
• 合并前统一同步最新基线

这比所有人直接在共享开发分支上堆提交更容易定位问题。
一旦某个功能需要推迟，只需要关闭那条分支，而不是从混合历史里拆弹。

7. 用例：版本进入冻结期后如何控制风险

当团队宣布“本周发版，今天开始冻结”时，流程应该立刻变化：

• 新功能停在主题分支
• 当前发版版本进入 release 分支
• 只允许明确需要进版的修复进入这条线

这种切换本质上就是分支生命周期在起作用，而不是简单多切一条分支。

8. 特殊情况：不是每个团队都需要完整 Git Flow

官方教材会介绍多种工作流，但并不是每个团队都需要完整的 develop、release、hotfix、support 体系。

如果团队规模不大，往往更适合：

• main 作为稳定主线
• 短命主题分支
• 必要时再临时开 release / hotfix 分支

规则越复杂，维护成本越高。
最佳实践不是“分支越多越专业”，而是“刚好足够表达协作边界”。

9. 一套适合中小团队的最低规则

可以先从这 6 条开始：

1. 主线必须保持可集成
2. 一项任务一个主题分支
3. 发布时才开 release 分支
4. 线上事故单独走 hotfix 分支
5. 发版后的修复必须同步回主线
6. 长期分支越少越好，职责越清晰越好

常见误区

• 把所有未完成工作长期堆在一条开发分支上
• 发布分支里继续混入大量新功能
• 热修复只修线上，不回灌主线
• 分支命名看起来有规则，但实际没人知道进入和退出条件

建议连着看

• 主题分支策略
• 提交评审前准备专题
• 发布卫生与版本边界