第324篇 Git 工作流：主干与多分支的选择

承接上一篇《代码评审清单：Android 团队的评审要点》，上一篇讲的是「单个 PR 怎么评审得有效」，这一篇往上一层：多个 PR 怎么组织、多个分支怎么合并、冲突怎么解决，才能让整个团队并行工作而不互相阻塞。

结论先行：分支策略的选择标准只有一个——「集成分支上任何时刻的代码是否可发布」。 Git Flow、GitHub Flow、Trunk Based Development 的差别都是围绕这一句展开的：前者用分支隔离风险（代价是合并地狱），后者用小步快跑 + 特性开关（代价是纪律要求更高）。

一、三种主流策略的实际形态

1.1 Git Flow

master ●──────────────────────────●──────────● (只接受 hotfix)
↑ ↑ ↑
release/1.0 ●─────●───────────●──────── (tag 打版)
↑ ↑ ↑
develop ●──────●───────●──●──────●──────●───●
↑ ↑ ↑ ↑ ↑
feature/A ●──────● ● │ │
feature/B ●──────●