简体繁体 English

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

[英]Branch-per-feature workflow using Mercurial

原文 2011-10-09 22:55:10 7 2 version-control/ mercurial

We have team of 10 developers who works parallel for different features, sometimes these features use common code sometime no. 我们有10个开发人员组成的团队，他们为不同的功能并行工作，有时候这些功能会使用通用代码。 And now we're changing our process to branch-per-feature and it seems mercurial is more suitable for such development. 现在我们正在将我们的流程改为按功能分支，而且似乎更适合这种开发。

I see this process so: 1. make release branch (rb) from default(trunk) 2. make feature branch (fb) from default(trunk) 我看到这个过程是这样的：1。从默认（主干）创建发布分支（rb）2。从默认（主干）创建功能分支（fb）

When developer thinks his feature is done he can merge fb to rb. 当开发人员认为他的功能完成后，他可以将fb合并到rb。 When it's time to go to QA we merge all finished fb to rb and create release for our QAs. 当我们去QA时，我们将所有已完成的fb合并到rb并为我们的QAs创建发布。

Questions: 问题：

When QA finds a bug developer should modify his fb and merge it again to rb. 当QA发现错误时，开发人员应该修改他的fb并将其再次合并到rb。 Does it mean that developer just switch to his fb and start fixing the bug and then makes simple merge fb to rb again? 这是否意味着开发人员只是切换到他的fb并开始修复bug然后再次简单地将fb合并到rb？
When release is passed QA it goes to PROD - how can we freeze changes? 当发布QA时，它会转到PROD - 我们如何冻结更改？ "hg tag" is good choice but someone can update tag if he really wants it. “hg tag”是不错的选择，但有人可以更新标签，如果他真的想要它。

Thanks 谢谢

2 个解决方案

If you're going to merging into specific release branches then your feature branches should be branched from the release branch, not the trunk. 如果您要合并到特定的发布分支，那么您的功能分支应该从发布分支而不是主干分支。 It is simpler to merge with the parent branch than a non-parent branch. 与父分支合并比非父分支更简单。

1) If you really want to do feature branches then each bug would have its own branch. 1）如果你真的想做功能分支，那么每个bug都有自己的分支。 This will help keep bug fixes separate from new features. 这将有助于将错误修复与新功能分开。 After all, it's branch-per-feature not branch-per-developer. 毕竟，它是每个功能的分支，而不是每个开发人员的分支。

2) Hg tag is what I have used. 2）Hg标签是我用过的。 You are right that someone change move a tag if they really want to, but tags are versioned and you can install hooks on the main hg repo to throw alerts if a tag is moved. 你是对的，如果有人改变移动标签，但标签是版本化的，你可以在主hg repo上安装钩子，以便在移动标签时抛出警报。 I really wouldn't worry about tags being moved unless you can't trust your developers, in which case you are screwed. 我真的不担心标签被移动，除非你不相信你的开发人员，在这种情况下你被搞砸了。

The answer to your first question is 'yes'. 你的第一个问题的答案是'是'。

The best way to freeze for release is to have a separate release clone that only the release manager can push/pull changesets to. 冻结发布的最佳方法是使用单独的发布克隆，只有发布管理器可以推送/拉动更改集。 Just because you're using branches doesn't mean multiple-clones don't have a place in your workflow. 仅仅因为您使用分支并不意味着多克隆在您的工作流程中没有位置。 Have a clone that QA does final pre-flight testing on to which developers can't push changes makes for a great firewall. 有一个克隆，QA做最后的飞行前测试，开发人员不能推动变化使得一个伟大的防火墙。

Also, consider using bookmarks for your feature branches. 另外，请考虑为功能分支使用书签。 Since, as I'm sure you know, Mercurial named branch names never go away the git-like bookmarks work well for sort lived concepts like features and bugs. 因为，我确定你知道，Mercurial命名的分支名称永远不会消失，类似git的书签适用于类似功能和错误的排序概念。