在做基于主干的开发时，什么东西会被部署到QA环境，什么时候部署？
假设在主干上有两个提交，分别是Feature A和Feature B，QA是否应该手动选择从Feature A的提交中进行构建，然后部署到QA服务器上？QA是否应该手动选择从包含Feature A的提交进行构建，并部署到QA服务器？如果在Feature A中发现了一个bug，会发生什么？在Feature B之后会有一个修复，因此部署到QA的下一个build也会包含Feature B。QA是否应该测试Feature A，而在该build中不测试Feature B？
或者我们应该总是将最新的构建从主干部署到QA，并包含所有最新的特性？但是在这种情况下，由于开发人员不停地将新特性推送到主干，越来越多的特性会在每一个新的构建后最终进入QA，测试永远不会完成，也不会有任何东西被发布到生产中。
你可以采取多种不同的方法。
如果你是定期发布（比如提供软件给其他人），那么最常见的方法是在通过一些标准（测试、代码审查等）后合并到主干，然后当你准备好后，在主干上创建一个冻结的分支，在那里进行QA测试，并应用任何必要的错误修复。 这通常需要有功能标志，这样开发人员就可以合并那些在最终准备好之前一直不活动的代码部分。
如果你没有定期发布，那么通常的做法是要求在合并前满足所有需求（包括QA）。 你仍然可以选择允许不活跃的代码逐步合并，但在合并开启功能的代码之前，你可能需要QA批准。 所以你会针对分支运行一个构建，并将其发送给QA进行测试。
一些做基于主干的开发的组织不做QA，让开发人员对自己的代码负责。 这在提供软件即服务的组织中很常见。 通常团队被分配到子系统，对子系统的修改需要该团队的批准。 由于开发人员负责整个服务的维护和部署，他们有动力不引起或不允许发生他们自己必须应对的事件。
所有这些方法都是常见的；然而，你真的可以在这里应用任何方法，它可以满足你作为一个组织的需求，也可以满足你的开发人员和QA人员的需求。 如果你不确定采取什么最好的方法，可以想出一些可能的方法，并与你的组织中的一些高级开发人员和QA人员讨论什么最能满足你的需求。 而且还要记住，如果你想出的方法不奏效，你可以在以后换一个效果更好的方法。