我遇到了一种情况，对此有点困惑。
这里的细节：-
假设我有一个构建自动化系统，两个开发团队a和B以及一个QE团队来验证构建。
我还有SVN用于源代码管理。我的行李箱很稳定，正在生产中运行。现在，为了进行并行开发，我创建了两个功能分支，Abranch用于团队A的功能，Bbranch用于B的功能。两人都开始惊叹他们树枝上的大特征，每一件东西看起来都很好。现在问题来了。
1) QE应该在哪里测试功能？(我只有一台QE服务器和一个QE数据库)
我们选择了开发人员应该制作一个小的、稳定的、可发布的功能子集和合并，以中继并继续在分支上工作。构建自动化将使构建包含更改，并将其部署在QE服务器上进行验证。(到目前为止似乎不错，但…)
假设团队A制作子功能并合并到trunk。现在就像SVN的书中所说的
SVN书上说
。。。另一种思考这种模式的方式是中继到分支的同步类似于在工作副本，而最后的合并步骤类似于运行svn从工作副本提交
团队B将中继的更新带到那里的分支。过了一段时间，他们也进行了分流和合并。现在QE正在测试一个构建中的两个子功能——一个来自团队a，一个来自球队B。(到目前为止仍然很好。)
现在，无论出于何种原因，QE都认为团队A的子功能不适合投入生产，并且只能发布团队B的任务。现在问题出现了，因为团队B的合并也包含了团队A的更改(当我们通过SVN手册，并在A合并了他们的子功能时用主干更新了B团队的feature分支)。
2) 如何处理这种情况？
答案是(可能是"其中之一"，但头痛程度最小)：
附加的QA分支，它只包含合并集(来自功能分支的合并)，并在通过QA测试和跨分支合并后作为到主干的合并的单一来源。从发布中排除的功能(之前通过了QA测试)必须通过相应合并集的反向合并从QA分支中删除