Git 工作流的选择：Trunk-Based vs GitFlow 的深度对比

分支策略决定了团队的交付节奏

「为什么我们的发布这么慢？」——很多团队的答案藏在分支策略里：多分支合并冲突、长生命周期的 feature 分支、发布前的巨型 merge——这些都是分支模型带来的摩擦。Trunk-Based 和 GitFlow 是两个极端，选哪个取决于团队规模与发布模式。

一、两种模式的核心理念

GitFlow：为「版本发布」设计

```

main（生产） ← release/1.2 ← develop ← feature/xxx

↑ ↑

hotfix/xxx ← feature 分支

```

• main：生产代码，每次合并打 tag；
• develop：集成分支，feature 完成后合入；
• feature：功能开发分支，可能存活数天到数周；
• release：发布准备分支（冻结功能，只修 bug）；
• hotfix：生产紧急修复。

适用场景：版本号明确的交付型产品（客户端 App、桌面软件、按版本售卖的企业软件）——「2.3.0 版本」有明确含义，发布节奏是月/季度级。

Trunk-Based：为「持续交付」设计

```

main（始终可发布）

↑ 短命分支（<2天）直接合入

↑ feature flag 控制功能可见性

```

• 只有 main 一个长生命周期分支；
• feature 分支短命（小时到天），合入后删除；
• 功能开关（Feature Flag） 控制「代码进主干但功能不可见」；
• 发布 = 从 main 部署最新通过 CI 的版本。

适用场景：Web 服务/SaaS 产品——每天发布多次，「版本」对用户透明。

二、深度对比

三、为什么大厂都在转向 Trunk-Based

Google/Meta/Netflix 都采用 Trunk-Based（或单仓库主干开发），原因：

1. 持续交付的前提——想做到「每天部署几十次」，分支必须短命。GitFlow 的 release 分支流程天然与持续交付冲突（release 分支的存在就是为了「冻结变更」）；
2. 减少集成债务——feature 分支存活两周意味着两周后才暴露集成问题。Trunk-Based 每天集成，问题当天发现当天修——「集成痛苦前置且摊薄」；
3. Feature Flag 解耦了「代码合入」与「功能上线」——代码可以先合（隐藏功能），功能后开（打开开关）——不需要为「功能未完成」保留分支。

四、Trunk-Based 的隐性门槛

1. 需要成熟的 CI——每次合入 main 触发全量测试（< 10 分钟），没有快速反馈的主干开发是灾难；
2. 需要 Feature Flag 基础设施——没有功能开关，未完成的功能代码进 main 会影响生产——自建或用 LaunchDarkly/Unleash；
3. 团队纪律——「小步提交」的文化（每次 PR < 400 行），大 PR 会让主干质量失控；
4. 测试覆盖——主干质量靠测试守，覆盖率低的团队上 Trunk-Based 是自杀。

五、务实建议：渐进式迁移

1. 第一步：缩短 feature 分支生命周期——从「功能完成才合并」改为「每 1-2 天合一次 WIP（Work In Progress）」——冲突更早暴露；
2. 第二步：引入 Feature Flag——新功能在 flag 后面开发，代码合入但功能关闭；
3. 第三步：砍掉 release 分支——直接从 main 部署（配金丝雀发布）；
4. 保留 GitFlow 的场景：多版本并行维护（同时支持 v1/v2 客户端）——这种场景 GitFlow 依然是正解。

结语

分支策略没有银弹——发布模式决定分支模型：版本化交付用 GitFlow，持续交付用 Trunk-Based。但如果你不确定，从「缩短分支生命周期 + 引入 Feature Flag」开始——这是两个模型通用的改进方向，也是走向持续交付的必经之路。