适用于小型团队的 Mercurial 工作流程
我在一个由 3 名开发人员组成的团队中工作，我们最近从 CVS 切换到 Mercurial。我们通过在每个工作站上拥有本地存储库并拉/推到开发服务器来使用 Mercurial。我不确定这是否是最好的工作流程，因为很容易忘记在提交后推送，并且 3 路合并冲突可能会导致真正的头痛。我们是否可以使用更好的工作流程，因为我认为目前分布式 VC 的复杂性超过了好处。
谢谢
I'm working in a team of 3 developers and we have recently switched from CVS to Mercurial. We are using Mercurial by having local repositories on each of our workstations and pulling/pushing to a development server. I'm not sure this is the best workflow, as it is easy to forget to Push after a Commit, and 3 way merge conflicts can cause a real headache. Is there a better workflow we could use, as I think the complexity of distributed VC is outweighing the benefits at the moment.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果您遇到很多三向合并，可能是因为您和您的团队成员正在做的事情有太多重叠。只要你们不编辑文件中完全相同的行，Mercurial 就可以很好地处理合并本身。如果可能的话，您可以更明确地划分工作，并避免大型合并带来的一些麻烦。另请注意，这仍然是 CVS 的一个问题，因为可以说它在合并方面比 Mercurial 更差。
您也不需要在每次提交后进行推送。您的工作流程可能如下所示：
在某种程度上，这看起来像走向黑暗，但是通过确保上例中的功能范围较小可以缓解这一问题。
If you are running into a lot of 3 way merges it might be because you have too much overlap in what you and your team members are working on. Mercurial is pretty good at handling merges itself, so long as you all aren't editing the exact same lines of a file. If possible, you could divide up the work more clearly and avoid some of the headaches of large merges. Also note that this would still be a problem with CVS since it's arguably worse at merging than mercurial.
You also don't need to push after every commit. Your workflow could look something like this:
To an extent, this looks like Going Dark, but that can be alleviated by making sure that the features in the above example are smallish in scope.
忘掉您对 CVS 的了解。 Mercurial 与它完全不同，即使有些命令感觉有些相似。
阅读http://hginit.com/。按照示例进行操作。
忘记您对 CVS 的了解。
我是说真的。这是最难的部分。学会信任你的工具。
Forget all you know about CVS. Mercurial is nothing like it even if some commands feel somewhat similar.
Read http://hginit.com/. Follow the examples.
Forget all you know about CVS.
I mean it. This is the hardest part. Learn to trust your tool.
听起来你们都在对同一个分支进行更改。这会产生令人不满意的副作用，即您几乎在每次提交时都会合并彼此的更改，这很好，除非您每次都不想手动干预冲突。推。
这是我建议的工作流程。这个想法是更多地使用分支，因此您需要更少地合并到主分支。
让每个开发人员在单独的分支中开发每个功能。这样：
您避免不断合并其他人的更改，并且
您没有压力将未完成的工作推给下一个人，“这使得合并变得困难。”
当某个功能“完成”时，如果更改看起来完全应用（判断调用），请将功能分支直接合并到主分支中并删除该功能分支。
如果某个功能远远落后于主分支（许多功能已合并），或者合并看起来很困难：
将 master 合并到功能分支中。
在与其他开发者的良好隔离中查找并修复任何错误。
假设该功能已准备就绪，请将其合并到 master 中（注意：现在根据定义，此方向上的合并将是干净的）。如果没有，您可以继续开发。
It sounds like you're all making your changes to the same branch. This has the unsatisfying side-effect that you're merging each others' changes on almost every single commit, which would be fine except that manually intervening for conflicts isn't something you want to do every time you push.
Here's the workflow I would suggest. The idea is to use branching more heavily, so you need to merge to the master branch less often.
Have every developer develop every feature in a separate branch. This way:
you avoid constantly merging changes from other people, and
you are free of the pressure to push incomplete work before the next guy, "makes it hard to merge."
When a feature is "done" and if the changes would appear to apply cleanly (a judgement call), merge the feature branch directly into the master branch and delete the feature branch.
If a feature falls way behind the master branch (many features merged), or if the merge otherwise appears difficult:
merge master into the feature branch.
Find and fix any bugs in contented isolation from other developers.
Assuming the feature is ready to go, merge it into master (notice: now the merge in this direction will be clean by definition). If not, you can just continue developing.
这对我来说听起来不错。我的团队规模大约是原来的两倍，而且运作良好。
您不必在每次提交后推送；当你想推的时候你就推。这就是 DVCS 的重要理念：提交和推送是截然不同的！
您是否经常使用相同的代码行？在我的 5-6 名程序员团队中，每天推/拉几次，每天提交多达几十次，我不记得上次必须手动解决合并冲突是什么时候了。当然不是在过去一两个月。
也许您应该更详细地描述您的工作流程，因为我在典型工作日遇到的集中版本控制的唯一复杂性可能是一个命令，而且好处是巨大的。与集中式版本相比，仅执行一次“hgblame”比我全年必须输入的所有“hgpush”节省了更多时间！
That sounds fine to me. My team is about double the size and it works great.
You don't have to push after every commit; you push when you want to push. That's the big idea about DVCS: that Commit and Push are distinct!
Are you working on the same lines of code a lot? On my team of 5-6 programmers, pushing/pulling a few times a day, and committing up to a couple dozen times a day, I can't remember the last time I've had to manually resolve merge conflicts. Certainly not in the past month or two.
Perhaps you should describe your workflow in more detail, because the only complexity over centralized version control that I encounter on a typical workday is maybe one command, and the benefits are huge. Doing "hg blame" just once saves me more time over the centralized version than all the "hg push"es I've had to type all year!
无论如何，我们是一个规模相似的团队，第一次与 Mercurial 合作，我们从同样的问题开始。
我们坚持了下来，现在情况明显好转了。我认为大多数问题都是在代码库很小并且人们都在尝试做同一件事时发生的。现在，它更加成熟了，人们不再那么互相打扰，巴黎也变得更小了。
希望你能顺利解决！
For what it's worth, we're a similar size team working with Mercurial for the first time and we started with the same problem.
We persisted and things are now significantly better. I think most of the problems occurred when the codebase was tiny and people were all trying to work on the same thing. Now that it's a little more established people aren't treading on each others' toes quite so much and the Paris much reduced.
Hope you get it sorted!