在进行基于主干的开发时，将什么部署到 QA 环境以及何时部署？
假设主干上有两个提交功能 A 和功能 B。QA 是否应该手动选择使用功能 A 提交构建并部署到 QA 服务器？如果在功能 A 中发现错误会发生什么？修复将在功能 B 之后进入主干，因此部署到 QA 的下一个构建也将包括功能 B。然后 QA 是否应该在该特定构建中测试功能 A 并使功能 B 未经测试？
或者我们是否应该始终将最新版本从主干部署到 QA，并包含所有最新功能？但在这种情况下，随着开发人员不停地将新功能推向主干，越来越多的功能将在每次新构建后最终进入 QA，测试永远不会完成，也不会发布任何东西到生产环境中。
您可以采取多种不同的方法。
如果您正在制作定期发布（例如向他人提供软件），那么最常见的方法是在通过一些标准（测试、代码审查等）后合并到主干中，然后当您准备好时，创建执行 QA 测试并应用任何必要的错误修复的冻结分支。这通常需要具有功能标志，以便开发人员可以合并部分保持不活动的代码，直到它们最终准备好。
如果您没有定期发布，那么通常的方法是要求在合并之前满足所有要求（包括 QA）。您仍然可以选择允许以增量方式合并非活动代码，但您可能需要 QA 批准才能合并启用该功能的代码。因此，您将针对分支运行构建并将其发送给 QA 进行测试。
一些进行基于主干开发的组织不进行 QA，而是让开发人员负责他们自己的代码。这在提供软件即服务的组织中很常见。通常，团队被分配子系统，对子系统的更改需要团队的批准。因为开发人员负责维护和部署他们的整个服务，所以他们被激励不引发或允许他们自己必须响应的事件。
所有这些方法都很常见。但是，您实际上可以在此处应用任何满足您作为组织的需求并同时满足您的开发人员和 QA 人员需求的方法。如果您不确定要采用的最佳方法，请提出一些可能的方法，并与您组织中的一些高级开发人员和 QA 人员讨论什么最能满足您的需求。还要记住，如果您想出一种行不通的方法，您可以稍后更改为另一种效果更好的方法。