7. Git 基础 2：分支策略（Git Flow / Trunk-Based）与发布节奏
分支策略决定 CI/CD 的复杂度与团队效率上限。
本章目标
学会选分支策略：不是“哪种更高级”，而是“哪种更匹配你的风险与节奏”。
你会掌握
Git Flow 与 Trunk-Based 的核心差异、发布节奏设计、以及与 CI/CD 门禁的组合方式。
真实收益
分支策略决定你的交付系统复杂度上限：选对了，CI/CD 是助推器；选错了，CI/CD 变成补锅工具。
分支策略本质上是在回答一个问题：我们如何把“变化”安全地送进主线？
你可以把它理解成交通规则：有的城市靠“红绿灯 + 限速”（门禁与小批量），有的城市靠“分车道 + 匝道”（长生命周期分支与发布分支）。
规则没有绝对优劣，但有明显的“适配场景”。
你可以把它理解成交通规则：有的城市靠“红绿灯 + 限速”（门禁与小批量），有的城市靠“分车道 + 匝道”（长生命周期分支与发布分支）。
规则没有绝对优劣，但有明显的“适配场景”。
1) 先把选择标准说清楚：你的约束是什么？
选策略之前先问 6 个问题：
- 发布频率：你希望一天多次，还是两周一次？
- 风险容忍：线上出错的代价多大？是否要求强合规审批？
- 团队规模：10 人以内还是上百人？跨团队协作多不多？
- 测试自动化：单测/集成/端到端覆盖是否足以支撑“快合并”？
- 环境与配置：多环境差异是否可控？是否有灰度与回滚能力？
- 系统形态：单体、微服务、还是 monorepo？
一句话总结：越想快，越依赖自动化门禁；越想稳，越依赖发布治理。
分支策略不是替代门禁，而是门禁的“组织方式”。
分支策略不是替代门禁，而是门禁的“组织方式”。
2) 两大阵营：Git Flow vs Trunk-Based（对比不是站队）
我们先用一句话给两者定性：
- Git Flow：用更多分支类型管理风险（release/hotfix），适合发布周期较长、治理较重的场景。
- Trunk-Based：尽量让变更快速回到主干，用小批量 + 强门禁 + 特性开关管理风险，适合高频交付。
图 1：两种分支策略的“形状”（动态）
左侧更像“多车道与匝道”，右侧更像“单车道 + 严格限速”。形状背后是风险管理方式的不同。
3) 发布节奏：你要设计的是“节奏”，不是“日期”
发布节奏常见三种：
- 连续交付（高频）：随时可发布；依赖强自动化与渐进发布。
- 固定节奏（中频）：例如每周二/四发布；强调窗口与回滚预案。
- 里程碑式（低频）：大版本发布；强调发布分支、变更冻结与回归周期。
图 2：从提交到发布的“节奏图”（动态）
节奏的关键是：变更如何排队、如何验证、如何进入环境，以及如何回退。
4) 门禁与风险控制：Trunk-Based 的“护栏”长什么样？
Trunk-Based 的核心不是“只有一个分支”，而是“把风险管理搬到门禁与交付”。典型护栏包括：
- 短生命周期分支：尽量当天合并，避免长期漂移。
- 必过检查：required checks（lint/test/安全扫描）。
- 小批量合并：降低冲突与回滚成本。
- 特性开关：让“合并”与“对外可见”解耦。
- 渐进发布：灰度、金丝雀、自动回滚。
图 3：护栏把风险“分段消化”（动态）
风险不是消失了，而是被切成更小的块：代码层门禁 → 发布层灰度 → 运行层观测。
5) 落地清单：你今天就能做的 8 件事
- 定义主线：明确主干分支（main/master）与保护规则。
- 强制门禁：至少 lint + 单测 + 构建通过才可合并。
- 缩短分支寿命：设定目标：分支不跨周，优先当天合并。
- 小批量合并：控制 PR 规模，避免“大爆炸合并”。
- 引入特性开关：合并与上线解耦，逐步减少长分支需求。
- 定义发布节奏：连续交付或固定窗口，写成明确规则。
- 回滚预案常态化：每次发布都要回答“如何回退”。
- 度量与改进：用 DORA/SLO 观察节奏是否健康，持续优化门禁与发布。
本章小结：分支策略 = 风险管理策略
- Git Flow 更依赖“分支结构”来管理风险；Trunk-Based 更依赖“门禁 + 小批量 + 交付护栏”。
- 发布节奏不是日期，而是流程：变更如何进入主线、如何验证、如何进入环境。
- 真正的成熟不是“选了某种策略”，而是能用护栏把风险分段消化。