Git 工作流终极对比：Trunk-Based vs Git Flow vs GitHub Flow

团队协作中，Git 分支策略的选择直接影响交付效率。三种主流方案各有适用场景。

Git Flow

Vincent Driessen 在 2010 年提出，分支结构：

• main：生产代码
• develop：开发主线
• feature/*：功能分支
• release/*：发布分支
• hotfix/*：热修复分支

优点：适合版本化发布（如移动 App、桌面软件）。缺点：分支多、合并复杂、CI/CD 不友好。

GitHub Flow

GitHub 自己用的极简方案：

1. 从 main 创建功能分支
2. 开发、提交、推送
3. 开 PR，Code Review
4. 合并到 main
5. 自动部署

优点：简单、适合持续部署。缺点：没有发布分支，不适合多版本并行维护。

Trunk-Based Development

Google、Meta 等大厂的选择：

• 所有人直接向 main（trunk）提交
• 短命功能分支（< 1 天）
• 用 Feature Flag 控制未完成功能
• 频繁集成，每天多次

优点：最小化合并冲突、持续集成的理想形态。缺点：需要强大的 CI、Feature Flag 基础设施、团队纪律。

怎么选？

小团队 + Web 服务 = GitHub Flow 或 Trunk-Based

中大团队 + 持续部署 = Trunk-Based

版本化产品（App、SDK）= Git Flow

开源项目 = GitHub Flow

Feature Flag 是关键

无论哪种工作流，Feature Flag 都是现代开发的标配：

if (featureFlags.isEnabled('new-checkout')) {
  return <NewCheckout />;
}
return <OldCheckout />;

推荐工具：LaunchDarkly、Unleash、Flagsmith（开源）。

我的建议

2026 年，如果你还在用 Git Flow 做 Web 服务，认真考虑迁移到 Trunk-Based。合并冲突减少、交付速度提升、团队幸福感上升。