总结

Git 工作流彼此之间并没有太大区别，大多数工作流都是建立在其他工作流的基础上的。与其将某种工作流视为一种教条，更重要的是遵循“快速失败”和“向前推进”的原则。所有的工作流实际上只是最佳实践的集合，你应该根据需要选择适合的部分。

重要的是你更改的大小以及你将它们合并回主分支的频率。

始终遵循以下规则：

  • 始终从主分支（基于 trunk）创建你的主题分支。

  • 如果你在处理复杂的功能，确保每天至少提交一次（使用功能标志）。

  • 如果你的更改很简单，只需要更改几行代码，你可以让 PR 保持开放较长时间。但要检查是否有太多的开放 PR。

按照这些规则，你实际上使用的工作流并不那么重要。挑选那些适合你的方法。

在本章中，你了解了 TBD（基于 trunk 的开发）的好处，以及如何结合 Git 工作流来提高工程效率。

在下一章，我将解释如何通过 shift-left 测试来提高质量，并更有信心地进行发布。

案例研究

通过自动化发布流程，两个试点团队已经注意到生产力的大幅提升。交付时间和部署频率的指标显著增加。

第一个团队在迁移到 GitHub 之前曾使用 Git，按照 Gitflow 分支工作流进行开发。由于他们的 Web 应用可以通过分阶段部署流程持续发布，因此他们转向了基于 trunk 的工作流，使用 PR 和私有分支，并在合并到 main 分支后通过 CI/CD 流程（MyFlow）进行部署。为了更频繁地进行集成，他们决定使用功能标志。由于公司需要在云端和本地都能管理功能标志，他们选择了 Unleash。该团队可以立即使用 SaaS 服务，而无需等待本地部署解决方案。

第二个团队原本使用 Team Foundation Server（TFS），习惯了复杂的分支工作流，包括长期存在的发布分支、服务包、热修复分支和一个集成所有功能的开发分支。由于软件安装在硬件产品上，多个版本会并行稳定，并且需要长期维护，这意味着无法进行持续发布。该团队选择了 release flow 来管理发布和热修复。对于开发，他们也采用了私有分支和 PR，且依然使用基于 trunk 的方法。由于产品无法连接到互联网，该团队依赖其配置系统来进行功能标志管理。这项技术以前就用于在硬件上测试新功能，团队现在将其扩展到更频繁地集成更改。

这两个团队的情况似乎都已经取得了很好的进展。如果有任何具体问题或挑战需要进一步解决，欢迎随时沟通！

进一步阅读

你可以通过以下参考资料，获取本章所涉及主题的更多信息：