使用Mercurial的按功能划分的工作流程

Question

我们有10名开发人员组成的团队，他们为不同的功能并行工作，有时候这些功能会使用通用代码。 现在我们正在将我们的流程改为按功能分支，看起来更加适合这种开发。

我看到这个过程： 1.从默认（主干）发布分支（r-b） 2.从默认（主干）

创建功能分支（f-b）

当开发人员认为他的功能完成后，他可以将f-b合并到r-b。当我们去QA时，我们将所有已完成的f-b合并到r-b并为我们的QAs创建发布。

问题：

1. 当QA发现错误时，开发人员应该修改他的f-b并将其再次合并到r-b。这是否意味着开发人员只需切换到他的f-b并开始修复bug然后再简单地将f-b合并到r-b？

2. 当发布时，QA会转到PROD - 我们如何冻结更改？ “hg tag”是不错的选择，但有人可以更新标签，如果他真的想要它。

由于

Answer 1

如果您要合并到特定的发布分支，那么您的功能分支应该从发布分支而不是主干分支。与父分支合并比非父分支更简单。

1）如果你真的想做功能分支，那么每个bug都有自己的分支。这将有助于将错误修复与新功能分开。毕竟，它是每个功能的分支，而不是每个开发人员分支。

2）Hg标签是我用过的。你是对的，如果有人改变移动标签，但标签是版本化的，你可以在主hg repo上安装钩子，以便在移动标签时抛出警报。我真的不担心标签被移动，除非你不相信你的开发人员，在这种情况下你被搞砸了。

Answer 2

第一个问题的答案是'是'。

冻结发布的最佳方法是使用一个单独的发布克隆，只有发布管理器可以推送/拉动更改集。仅仅因为您使用分支并不意味着多克隆在您的工作流程中没有位置。有一个克隆，QA做最后的飞行前测试，开发人员不能推动更​​改，使一个伟大的防火墙。

另外，请考虑为功能分支使用书签。因为，我确定你知道，Mercurial命名的分支名称永远不会消失，类似git的书签适用于排序等概念，如功能和错误。