我已经使用mercurial已经有一段时间了，但还没有真正习惯使用分支机构，所以在将它应用到真实项目之前，我正在努力弄清楚这个工作流程是否有意义。
问题：
每次我们通过将development合并到新版本来复制production分支时，是否真的有意义，或者我们应该创建像{一样的唯一命名的短期开发分支{1}}？
工作流程描述：
我们代码的每个生产就绪版本都会被标记（development-1.1，1.0等等）并放在1.1分支中。一旦我们将production投入生产，我们立即开始处理下一个版本 - 1.0，打开一个名为1.1的分支，然后由每个开发人员进行子分支每个指定的功能，以保持整洁。到目前为止非常简单。
然后测试development分支，现在包含合并中的development分支，并将其合并回feature，因为这些更改已被视为生产就绪。
当我们需要继续处理即将发布的版本production时，我们将1.2 - 分支合并到production分支并开始工作。
修订版的图解历史记录：
development答案 0 :(得分：6)
使用Mercurial 命名分支是永远的，因此一般建议只将它们用于始终适用的名称。像“稳定”和“开发”之类的东西，而不是“bug-194534”和“release-1.1”之类的东西。这很好地解释了in the wiki。
对于具有有限寿命的东西，你最好使用像书签这样的东西，它们更接近git调用分支而不是Mercurial命名分支。短期概念的其他很好的选择是匿名分支或克隆，两者都是非永久性的。
一般建议是使用default as your development branch，但简而言之，是，继续重复使用相同的分支进行开发。
答案 1 :(得分：1)
您正在描述的工作流程看似合理，因为它与git-flow工作流程类似。
http://nvie.com/posts/a-successful-git-branching-model/。
它很受欢迎（我猜），所以期望任何开发者都能理解它是合理的。这是值得的。我不知道通过使用短期dev-1.1分支等改变它可以带来什么额外的价值。似乎管理这些的开销可能会超过成本。