我们要换成Mercurial。 我们计划中缺少的一个部分是如何管理构建到Test Box（和LiveBox）的分支/合并，因此可以将独立的功能与StableRelease混合并构建到TestBox。
例如，似乎主要用途是
FeatureA和FeatureB的开发将同时进行。看起来主要用途是将克隆的存储库与上面的分支一起使用。
场景1：如果我们构建测试，我们将合并LiveCode + FeatureA + FeatureB。如果一切顺利，那么我们可以将变更集合并到上游到DefaultStable分支，并使用FeatureA和FeatureB构建到LiveBox。完成工作。
场景2：如果我们构建测试，我们将合并LiveCode + FeatureA + FeatureB，QA显示FeatureB存在问题。我们不想再建立FeatureB了。我们确实想要进步FeatureA。我们想要自己重新测试FeatureA并让QA通过它。然后将其发布到Live以及业务敏捷性。
问题： 如果FeatureB未通过QA，我们需要从Test Branch中取出FeatureB变更集节点，再次构建到TesBox，然后希望将上游合并到DefaultStable分支到LiveBox。 从TestBranch中删除FeatureB变更集节点的最佳方法是什么，因为1.我们在FeatureB上需要更多dev，并且FeatureB节点集没有finsihed。 2.我们需要隔离DefaultStable + FeatureABranch并构建它以进行测试
其他人如何管理这个？
答案 0 :(得分：2)
Mercurial工作流程有很多很棒的写作，包括：
所有这些都使用Named Branches非常小 - 绝对不是每个功能一个，克隆作为分支听起来像你（和我）喜欢的工作模式。
遇到您的具体问题，如果LiveCode + FeatureA + FeatureB组合测试失败，最好的方法就是继续修复FeatureB，然后将这些更改合并到FeatureA + Feature B中。但是，在您到达之前在那个阶段，让QA分别点击LiveCode + FeatureA和LiveCode + FeatureB是一个好主意，它对他们来说稍微有点工作（更多的测试目标）但是隔离每个功能有助于更快地找到缺陷的原因。
一旦LiveCode + FeatureA和LiveCode + FeatureB传递QA，然后您将它们合并到LiveCode + FeatureA + FeatureB中，如果仍然通过测试，则将整个事物合并到DefaultStable中。不需要从LiveCode + FeatureA + FeatureB中删除 FeatureB，因为您可以随时创建LiveCode的新克隆，并在需要时仅在FeatureA中合并。
以下是基于Mercurial（Kiln）的质量保证/发布流程的精彩撰写：
答案 1 :(得分：1)
在stable中的功能克隆分支中创建FeatureA和FeatureB。测试只是质量保证/测试工作的临时区域，所以从第一天开始我就把它视为“一次性”。
当FeatureA和FeatureB足够开发时，创建一个克隆，然后将另一个拉入QA / Test。为QA构建，当他们提供反馈时，对FeatureB进行适当的更改。
如果FeatureA可以接受促销，请将其拉入/推送至Stable，然后合并为stable。
这比我原来的帖子更清楚了吗？