我们将换用Mercurial。
我们计划中缺少的一个部分是如何管理构建到Test Box（和LiveBox）的分支/合并，因此可以将孤立的功能与StableRelease混合并构建到TestBox。
例如，似乎主要用法是
DefaultStableBanch
测试包
FeatureABranch
FeatureBBranch
在FeatureA和FeatureB上的开发将同时进行。似乎主要用途是克隆带有上面分支的存储库。
方案1：如果要进行测试，我们将合并LiveCode + FeatureA + FeatureB。如果一切顺利，那么我们可以将变更集合并到DefaultStable分支的上游，并使用FeatureA和FeatureB构建到LiveBox。任务完成。
方案2：如果进行测试，我们将合并LiveCode + FeatureA + FeatureB，并且质量检查表明FeatureB存在问题。我们不想再构建FeatureB。我们确实希望改进FeatureA。我们希望自己对FeatureA进行重新测试，然后让质量检查通过。然后将其发布到Live，从而实现业务敏捷性。
问题：
如果FeatureB无法通过质量检查，我们需要从测试分支中取出FeatureB变更集节点，再次构建到TesBox，然后希望将上游合并到DefaultStable分支，再合并到LiveBox。
从TestBranch删除FeatureB变更集节点的最佳方法是什么，因为1.我们需要FeatureB上更多的开发人员，并且FeatureB节点集尚未确定。
2.我们需要隔离DefaultStable + FeatureABranch并进行测试
其他人如何管理呢？
最佳答案
Mercurial工作流有很多很棒的文章，包括：
http://stevelosh.com/blog/2010/02/mercurial-workflows-branch-as-needed/
http://stevelosh.com/blog/2010/05/mercurial-workflows-stable-default/
https://www.mercurial-scm.org/wiki/StandardBranching
所有这些都非常少地使用Named Branches －绝对不是每个功能一个，使用克隆作为分支听起来像您（和我）喜欢的工作模式。
碰到您的特定问题，如果LiveCode + FeatureA + FeatureB组合未通过测试，最好的解决方法是继续修复FeatureB，然后将这些更改合并到FeatureA + Feature B中。但是，在进入该阶段之前，是将质量检查也分别打在LiveCode + FeatureA和LiveCode + FeatureB上是一个好主意，对他们来说，要花更多的精力（更多的测试目标），但是将每个功能单独隔离有助于更快地找到缺陷的原因。
一旦LiveCode + FeatureA和LiveCode + FeatureB通过了质量检查，然后将它们合并到LiveCode + FeatureA + FeatureB中，如果仍然通过测试，则将整个内容合并到DefaultStable中。无需从LiveCode + FeatureA + FeatureB中删除FeatureB，因为您始终可以只创建LiveCode的新副本，并在需要时仅合并FeatureA。
这是基于Mercurial（Kiln）的质量检查/发布过程的精彩文章：
http://blog.bitquabit.com/2011/03/10/when-things-go-well/