适合 15 名开发人员的团队的良好 Mercurial 工作流程
我所在的团队有 15 名开发人员，目前正在使用 Allfusion Harvest。我们对此并不满意，考虑到有可用的前端 TortoiseHg 和 MercurialEclipse，我们决定改用 Mercurial。
我们目前使用的是 Harvest 的 12 年前版本，我发现我们当前的工作流程很难转换为 Mercurial。我之前使用过 ClearCase，我们使用的模型类似于：
A A A
| | |
B C |
| /| |
C | E
| | /
D E
| /
E
左树干不稳定，中间测试，右树干稳定。现在，我可以在 Mercurial 中（在一个中央存储库中）重新创建此分支模型了。这个想法是，开发人员然后克隆这个存储库，从不稳定分支出来，完成他们的工作，然后与不稳定合并。在网上阅读时，我还没有看到针对超过三名开发人员的团队的 Mercurial 工作流程，因此我不确定这是否是一个好的工作流程。
所以有两个问题：
这是一个很好的工作模型吗？
您如何使用 Mercurial 以及您的团队中有多少人？
编辑：自从问这个问题以来，我已经使用过Gitflow 和 Github 流程。根据发布复杂性和团队规模，两者都很有用。当使用 Mercurial 时，我已经停止使用分支（除了稳定/不稳定），而是使用受 Git 影响的书签。
I'm in a team of 15 developers currently using Allfusion Harvest. We're not happy with it and looking around we've decided to switch to Mercurial due to the available frontends TortoiseHg and MercurialEclipse.
We're currently using a twelve year old release of Harvest and I find our current workflow hard to translate to Mercurial. I have previous experience with ClearCase where we used a model similar to:
A A A
| | |
B C |
| /| |
C | E
| | /
D E
| /
E
Where the left trunk is unstable, middle is test and right is stable. Now I have no problem recreating this branching model in Mercurial (in one central repository). The idea is that the developers then clone this repository, branch out from unstable, do their work and then merge with unstable. Reading on the web I've yet to see a Mercurial work flow aimed at teams larger than three developers so I'm unsure if this is a good workflow.
So two questions:
Is this a good working model?
How do you work with Mercurial and how many are there in your team?
EDIT: Since asking this question I've used both Gitflow and Github flow. Both has been useful depending on release complexity and team size. And when using Mercurial I've stopped using branches (for other than stable/unstable) and made use of the Git influenced bookmarks instead.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在 Fog Creek，我们使用类似的工作流程，但有一个主要区别。因为 Mercurial 中没有真正的轻量级分支（命名分支即使在合并后也保留其名称），我们倾向于为分支使用多个存储库。我发现这使得您更容易知道您正在处理哪个分支，并且也使得分支之间意外合并变得更加困难，因为您的每个分支都可以拥有自己的临时分支。
相反，我们有稳定的、QA 和开发仓库可供使用。功能工作进入 Devel 并合并到 QA 和 Stable，而错误修复则进入 Stable 和 QA，然后合并回 Devel。
我们的许多开发人员还保留自己的分支存储库，以用于运行时间较长的项目，或者他们正在处理的任何可能会破坏其他人代码的项目。
我们的一些开发人员将每个分支都放在不同的目录中，因此他们明确地从一个分支切换到另一个目录。其他人更喜欢将所有三个合并到一个存储库中，使用 remote-branches 扩展来管理各个头。
当我们使用基本的 hgserve 来托管我们的存储库时，这确实给我们带来了一些麻烦，因为创建新的开发存储库或重命名存储库需要系统管理员。这就是我们这样做的部分原因，以便任何人都可以在 Kiln 中创建分支存储库。
如果 Mercurial 有一个更好的分支模型，那就太好了，并且正在进行一些工作来帮助实现这一点，但这对我们来说是有效的。
Here at Fog Creek, we use a similar workflow, with one major difference. Because there aren't really lightweight branches in Mercurial (named branches keep their name, even after being merged) we tend to use multiple repositories for our branches. I've found that this makes it easier to know which branch you're working on, and also makes it harder to accidentally merge between branches, since each of your branches could have ad-hoc branches of its own.
Instead, we have Stable, QA, and Devel repos that we work with. Feature work goes into Devel and merges up to QA and Stable, while bug fixes go into Stable and QA, and are merged back into Devel.
A lot of our devs also keep their own branch repos for longer running projects, or anything that they're working on that might break someone else's code.
Some of our devs have each branch in a different directory, so they are explicitly switching from one to another. Others prefer to pull all three into one repo, using the remote-branches extension to manage the various heads.
This did give us a bit of trouble when we were using the basic
hg serveto host our repos, since creating a new devel repo or renaming repos required a sysadmin. That's part of why we made it so anyone can create branch repos in Kiln.It would be nice if Mercurial had a better branching model, and there is some work going on to help with that, but this is what works for us.