主干开发 (Trunk-based)

随着 DevOps 和持续集成/持续交付 (CI/CD) 的兴起，主干开发 (Trunk-based Development, TBD) 逐渐成为很多高性能技术团队常见的工作流实践（业界案例包括 Google、Facebook、Netflix 等）。

它的核心理念是：所有的开发都应当频繁地合并到单一的主干分支（Trunk/Main），避免长期的特性分支。

核心原则

1. 单一主干

只有一个长期的分支，通常是 main 或 master，我们称之为“主干”。所有的发布都直接从主干进行（或者从主干切出一个短期的发布分支）。

2. 短命分支 (Short-lived Branches)

开发者可以在本地创建分支，但这些分支的寿命通常只有几天甚至几小时。一旦代码通过编译和基本测试，就必须合并回主干。

3. 频繁提交

鼓励开发者至少每日向主干集成一次代码，小步合入。

这种模式如何工作？

你可能会问：“如果功能还没做完，合并进去不会破坏主干吗？”

为了解决这个问题，TBD 依赖两个关键技术：

功能开关 (Feature Flags)

未完成的功能代码虽然合并进了主干，但被包裹在特性开关中。

if (featureFlags.isOn('new-ui')) {
    renderNewUI(); // 正在开发中的功能
} else {
    renderOldUI(); // 现有稳定功能
}

这允许你在生产环境中部署包含“半成品”代码的版本，但在开关打开之前，用户对它是无感知的。

自动化测试

由于合并非常频繁，人工回归测试是不可能的。TBD 必须依赖强大的自动化测试套件（单元测试、集成测试）来充当“看门人”，确保坏代码不会混入主干。

与 Gitflow 的对比

特性	Gitflow	主干开发 (TBD)
分支寿命	长（几天到几周）	极短（几小时到一两天）
合并频率	功能完成后	持续不断，哪怕功能未完成
发布方式	预定的 Release 分支	随时从主干部署
代码冲突	常见，解决痛苦	罕见，冲突很小
依赖	严格的流程管理	强大的自动化测试和功能开关

优缺点分析

优点

1. 极速反馈：代码越早合并，就能越早发现集成问题。
2. 避免“合并地狱”：不再有积累了几周代码的巨大 Merge Conflict。
3. 支持 CI/CD：主干时刻处于“可发布”状态，非常适合自动化流水线。
4. 代码可见性：每个人都能看到其他人正在写的代码，减少了重复造轮子。

缺点

1. 门槛高：需要团队有极高的工程素养（自动化测试覆盖率高、熟练使用功能开关）。
2. 基础设施要求：没有完善的 CI 系统，主干很容易被破坏（Broken Build）。
3. 思维转变：开发者需要习惯“提交未完成的代码”，这对很多人来说是反直觉的。

应该选择 TBD 吗？

• 如果是：

  • 你们正在实施 CI/CD。
  • 团队有良好的测试文化。
  • 产品需要快速迭代，每天多次发布。
  • 选择主干开发。

• 如果是：

  • 开源项目（不可信的贡献者）。
  • 测试完全依赖人工。
  • 无法容忍任何时刻的主干不稳定。
  • 坚持 Gitflow 或 Forking 工作流。

总结

主干开发是软件工程进化的方向。它用自动化的信心取代了流程的繁琐。如果你的团队感到 Gitflow 的合并过程痛苦不堪，尝试向 TBD 转型通常是正确的解药。