基于主干开发的优点 | AI生成和翻译
问题：反对使用多个 Git 分支（如 Git Flow），转而使用带有功能开关的单个主分支的理由是否充分，尤其是声称团队可以将发布周期从几天缩短到每天 20 次以上的部署且零事故的说法？
答案：
在现代软件工程中，这种观点非常有力——特别是对于构建 Web 服务、SaaS 产品或任何持续交付系统的团队而言。这种方法通常被称为“主干开发”（Trunk-Based Development，TBD）+ 功能开关，它是 Google、Facebook、Netflix 和大多数“大规模”科技公司今天运营的支柱。
反分支论点为何成立
| 长期存在的功能分支（Git Flow 风格）的问题 | 主干开发 + 功能开关如何解决 |
|---|---|
| “没人知道生产环境中到底有什么”（合并地狱、集成债务） | 每个人都在 main 上工作。生产环境中的提交与每个开发人员本地的提交（或非常新的提交）是完全相同的。 |
| 持续的合并冲突和集成意外 | 持续集成是真实的——你每天集成多次，而不是每几周一次。 |
| 发布规模大、风险高、速度慢（几天/几周） | 你将完全相同的提交部署到所有环境。新代码隐藏在功能开关后面，直到准备好 → 你可以安全地每天部署 20-100 次。 |
| 热修复需要 cherry-picking 和特殊分支 | 热修复 = 提交到 main + 部署 + 切换开关（或回滚开关）。无需特殊分支。 |
| 回滚令人恐惧（撤销两周的功能批次） | 回滚 = 关闭功能开关或部署之前的提交。只需几秒，而非几小时/几天。 |
真实世界的证据
- Google、Facebook 和 Microsoft 已经进行主干开发 15 年以上，并发布论文表明，尽管每天部署数千次，但部署事故几乎为零。
- 2023 年 DevOps 状态报告（Accelerate / DORA）继续显示，优秀团队（每天部署 >100 次，交付周期 <1 小时）绝大多数使用主干开发和功能开关。
- Netflix 曾以每季度发布一次而闻名，但在采用这种模式后，每天部署数千次。
- Shopify、Etsy 和许多金融科技公司公开表示，每天 20-100 次部署和零停机归功于这种确切的转变。
“每天 20 次以上部署且零事故”的说法
这不是营销炒作——对于采用这种模式的成熟团队来说，这是常规操作。一旦你停止将功能批量发布，而是将每个提交都通过功能开关发布，部署就会变成一件完全不值一提的事情。唯一可能导致生产环境故障的是错误的开关切换（可以立即逆转）或数据迁移问题，而这些比长期分支带来的集成错误要罕见得多。
分支仍然有用的时候
- 有许多外部贡献者的开源项目（拉取请求模型很好）。
- 没有良好功能开关基础设施的超大型单体应用（但即便如此，大多数团队最终也会投入到功能开关并转向主干）。
- 法律要求“发布包”的受监管环境（医疗保健、航空航天）——尽管其中许多也正在转向基于功能开关的持续部署和审计跟踪。
结论 是的，这个论点非常充分。对于今天几乎所有的产品/开发团队来说，长期存在的功能分支是一种反模式，它直接导致了缓慢、有风险、痛苦的发布。切换到单个主分支 + 功能开关，通常能实现发帖人所声称的部署频率和稳定性 10-100 倍的改进。
参考资料：
- Accelerate: DevOps 状态报告（多年）
- 主干开发网站和案例研究
- Google 关于每天 >100 次部署的论文（2016 年，仍然适用）
- [大规模功能开关——LaunchDarkly / Optimizely 案例研究]