由15位开发人员组成的团队的Mercurial工作流程

时间:2010-08-24 15:42:29

标签: mercurial workflow

我是一个由15名开发人员组成的团队,目前正在使用Allfusion Harvest。我们对此并不满意并且环顾四周我们已经决定切换到Mercurial,因为可用的前端是TortoiseHg和MercurialEclipse。

我们目前正在使用已有1​​2年历史的Harvest,我发现目前的工作流难以转化为Mercurial。我之前有使用ClearCase的经验,我们使用的模型类似于:

A  A  A
|  |  |
B  C  |
| /|  |
C  |  E
|  | /  
D  E
| /
E

左侧主干不稳定,中间是测试,右侧是稳定。现在,我在Mercurial(在一个中央存储库中)重新创建这个分支模型没有问题。我们的想法是,开发人员然后克隆此存储库,从不稳定分支出来,完成他们的工作,然后与 unstable 合并。在网上阅读我还没有看到针对三个以上开发人员的团队的Mercurial工作流程,所以我不确定这是否是一个很好的工作流程。

所以有两个问题:

这是一个好的工作模式吗?

您如何使用Mercurial以及团队中有多少人?

编辑:自从提出此问题以来,我同时使用了GitflowGithub flow。根据发布复杂性和团队规模,两者都很有用。当使用Mercurial时,我已停止使用分支(除稳定/不稳定之外)并使用受Git影响的书签。

2 个答案:

答案 0 :(得分:5)

在Fog Creek,我们使用类似的工作流程,但有一个主要区别。因为Mercurial中没有真正的轻量级分支(命名分支保留其名称,即使在合并之后),我们倾向于为分支使用多个存储库。我发现这样可以更容易地知道你正在处理哪个分支,并且更难以在分支之间意外合并,因为每个分支都可以拥有自己的特殊分支。

相反,我们拥有与之合作的Stable,QA和Devel回购。功能工作进入Devel并合并到QA和Stable,而错误修复进入Stable和QA,并合并回Devel。

我们的许多开发人员也会为更长时间运行的项目保留自己的分支存储库,或者他们正在处理的任何可能会破坏其他人代码的事情。

我们的一些开发人员将每个分支放在不同的目录中,因此他们明确地从一个目录切换到另一个目录。其他人更喜欢将所有三个转换为一个回购,使用remote-branches扩展来管理各个头。

当我们使用基本的hg serve来托管我们的存储库时,这确实给我们带来了一些麻烦,因为创建一个新的devel repo或重命名repos需要一个sysadmin。这就是我们制作它的原因之一,所以任何人都可以在Kiln创建分支回购。

如果Mercurial拥有更好的分支模型会很好,并且有一些工作可以帮助解决这个问题,但这对我们有用。

答案 1 :(得分:1)

  • 就我所知,您的工作流程非常好。