问题描述
作为一家小型B2B SaaS公司的主要开发人员，我们使用Django和AWS。目前我们使用自定义的Fabric工具进行半月部署，主要在工作时间之后完成，而且部分自动化。
我们目前正在探索将部署完全自动化到夜间，并且希望采用不同的分支模型来支持这一点。
当前情况下，我们从开发分支创建主题分支，然后将主题分支合并回开发分支。开发分支是一个长期存在的分支，在每个半月的生产部署过程中会全量合并到主分支，使用--no-ff选项。这导致在发布日前需要进行功能冻结，以确保破坏性的代码不会在发布前合并，这并不是一个理想的解决方案。
我的当前计划是采用更加面向分支的工作流，类似于Gitworkflow：https://github.com/rocketraman/gitworkflow。这将允许我们将功能/错误修复分支逐个合并到开发分支，然后只有通过了手动QA的分支（对应Jira问题）才会合并到主分支。
这是否是一个好的方法？
我心中有一些潜在的问题，比如如何处理未通过QA的问题/分支，以及应该从开发分支/环境中删除它们。我想，我们可以通过使用主分支来”刷新”开发环境，然后重新将正在进行QA的所有分支合并回去，而不是撤销提交…
解决方案
请注意以下操作注意版本差异及修改前做好备份。
GitFlow与TBD
在处理自动化夜间部署以及分支管理模型时，有两个主要的派系：支持GitFlow和支持其他方法（TBD为主）。个人而言，我更偏向TBD与发布分支的组合，但你会发现很多其他人认为GitFlow更好，所以你需要根据实际情况做出决定。
GitFlow：在GitFlow中，你会在发布前从主分支切出一个发布分支。在这个分支上进行测试和修复，而主分支可以继续开发。这个方法对于部署频率较低的情况可能更合适。你可以参考这篇文章深入了解：https://nvie.com/posts/a-successful-git-branching-model/。
TBD（Trunk-Based Development）：TBD模型更注重主分支的稳定性，开发人员持续向主分支提交，而在发布前进行测试。这对于频繁部署以及持续交付（CD）非常有用。你可以在这里了解更多：https://trunkbaseddevelopment.com/，特别是查看”Scaled Trunk-Based Development”章节。
针对TBD的调整
从你的需求来看，你希望在TBD模型中对开发分支进行调整，以支持UAT（用户验收测试）的拒绝情况。你的想法类似于gitworkflow：https://github.com/rocketraman/gitworkflow。在这个模型中，你可以将开发分支中的主题逐个”推进”到一个UAT分支/环境，然后再将通过测试的主题合并回主分支。这可以在以下几个步骤中实现：
- 创建一个UAT分支，用于进行用户验收测试。
- 将每个主题分支逐个合并到UAT分支。
- 在UAT环境中进行测试，如果发现问题，则在UAT分支上进行修复。
- 一旦主题通过了UAT，将其合并回主分支。
这种方法可以确保只有通过了测试的主题才会进入主分支，从而保持主分支的稳定性。需要注意的是，你可能需要在UAT分支中进行一些清理操作，以确保不通过测试的主题不会影响主分支的稳定性。
持续改进
你提到目前的测试覆盖率还不足以让你完全放心使用TBD模型。这是一个理解的观点。在采用新的工作流程前，逐步增加测试覆盖率是一个明智的决策。你可以根据团队的进展，逐步实施更严格的TBD模型。
总结
在实现夜间部署的过程中，你可以考虑从传统的GitFlow模型向更灵活的TBD模型过渡，以支持更频繁的部署。在TBD模型中，你可以根据主题逐个推进到UAT分支，然后再合并回主分支，以确保稳定性和质量。然后，你可以根据团队的进展逐步改进测试覆盖率，使整个流程更加自动化和可靠。