适合小团队的Mercurial Workflow

Question

我在一个由3名开发人员组成的团队中工作，最近我们从CVS转到了Mercurial。我们使用Mercurial，在每个工作站上安装本地存储库，并将其拉/推送到开发服务器。我不确定这是最好的工作流程，因为在提交后很容易忘记推送，而且3路合并冲突可能会引起真正的麻烦。我们可以使用更好的工作流程，因为我认为分布式VC的复杂性超过了目前的好处。

由于

Answer 1

如果您遇到很多3路合并，可能是因为您和您的团队成员正在处理的内容有太多重叠。 Mercurial非常善于处理合并本身，只要你们都没有编辑完全相同的文件行。如果可能的话，你可以更清楚地划分工作，避免一些大合并的麻烦。另请注意，这仍然是CVS的一个问题，因为它在合并时可能会比mercurial更糟糕。

每次提交后也不需要推送。您的工作流程可能如下所示：

• 承诺部分功能。
• 提供更多功能。
• 提交功能的最后一部分。
• 为愚蠢的错误提交错误修复。
• 将完整功能推送至repo。

在某种程度上，这看起来像Going Dark，但可以通过确保上面示例中的功能范围很小来缓解这种情况。

Answer 2

1. 忘掉你对CVS的所有了解。即使某些命令有些相似，Mercurial也不像它。

2. 阅读http://hginit.com/。请按照示例进行操作。

3. 忘掉你对CVS的所有了解。

4. 我的意思是。这是最难的部分。学会相信你的工具。

Answer 3

听起来你们都在对同一个分支进行更改。这有一个令人不满意的副作用，你几乎每次提交都会合并彼此的变化，除了手动干预冲突不是你想要做的事情每个时间你推。

这是我建议的工作流程。我们的想法是更频繁地使用分支，因此您需要更少地合并到主分支。

1. 让每个开发人员在单独的分支中开发每个功能。这样：

   • 您可以避免不断合并其他人的更改，

   • 你没有压力在下一个人面前推动不完整的工作，“难以合并。”

2. 当某个功能“完成”并且更改看起来干净利落（判断调用）时，将功能分支直接合并到主分支并删除功能分支。

3. 如果某个功能落后于主分支（合并了许多功能），或者合并其他方式很难：

   1. 将master 合并到功能分支中。

   2. 查找并修复与其他开发人员相关的任何错误。

   3. 假设该功能已准备就绪，请将其合并到master中（注意：现在根据定义，此方向的合并将是干净的）。如果没有，你可以继续开发。

Answer 4

  

我们通过在每个工作站上安装本地存储库并拉/推到开发服务器来使用Mercurial。

这听起来不错。我的团队规模只有两倍，效果很好。

  

我不确定这是最好的工作流程，因为在提交后很容易忘记推送，

每次提交后都不必推动;当你想要推动时你推。这是关于DVCS的一个大概念：提交和推送是截然不同的！

  

和3种方式的合并冲突可能会引起真正的麻烦。

您是否经常使用相同的代码行？在我的5-6名程序员团队中，每天推/拉几次，每天最多进行几十次，我不记得上次我必须手动解决合并冲突。当然不是在过去一两个月。

  

我们可以使用更好的工作流程，因为我认为分布式VC的复杂性超过了目前的好处。

也许您应该更详细地描述您的工作流程，因为我在典型工作日遇到的集中版本控制的唯一复杂性可能是一个命令，并且好处是巨大的。只做一次“hg blame”比集中版本节省的时间比全年输入的所有“hg push”更多！

Answer 5

对于它的价值，我们是第一次与Mercurial合作的类似规模的团队，我们也遇到了同样的问题。

我们坚持不懈，现在情况好多了。我认为大多数问题都发生在代码库很小并且人们都试图处理相同的事情时。现在它已经变得更加成熟，人们并没有踩到彼此。脚趾非常多，巴黎大大减少了。

希望你把它分类！