小团队的Mercurial Workflow

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

已邀请:

5 个回复

壬驴拿歪竞

如果您遇到很多3路合并，可能是因为您和您的团队成员正在处理的内容有太多重叠。 Mercurial非常善于处理合并本身，只要你们都没有编辑完全相同的文件行。如果可能的话，你可以更清楚地划分工作，避免一些大合并的麻烦。还要注意，这仍然是CVS的一个问题，因为它在合并时可能比mercurial更糟糕。每次提交后也不需要推送。您的工作流程可能如下所示：承诺某些功能的一部分。提交更多功能。提交功能的最后一部分。为愚蠢的错误提交bug修复。将完整功能推送到repo。在某种程度上，这看起来像Going Dark，但可以通过确保上面示例中的功能范围很小来缓解这种情况。

翱抹村

忘掉你对CVS的所有了解。即使某些命令有些相似，Mercurial也不会像它一样。阅读http://hginit.com/。按照例子。忘掉你对CVS的所有了解。我是认真的。这是最难的部分。学会相信你的工具。

告耸

听起来你们都在对同一个分支进行更改。这有一个令人不满意的副作用，你几乎每次提交都会合并彼此的变化，除了手动干预冲突不是你每次推动时都想做的事情。这是我建议的工作流程。我们的想法是更频繁地使用分支，因此您需要更少地合并到主分支。让每个开发人员在单独的分支中开发每个功能。这条路：你不要经常合并来自其他人的变化，并且你没有在下一个人面前推动不完整工作的压力，“让人难以合并。” 当某个功能“完成”并且更改看起来干净利落（判断调用）时，将功能分支直接合并到主分支中并删除功能分支。如果某个功能落后于主分支（许多功能已合并），或者合并出现困难：将master合并到功能分支中。查找并修复与其他开发人员相关的任何错误。假设该功能已准备就绪，请将其合并到master中（注意：现在，根据定义，此方向的合并将是干净的）。如果没有，你可以继续开发。

踩什不

我们使用Mercurial，在每个工作站上安装本地存储库，并将其拉/推送到开发服务器。这听起来不错。我的团队规模只有两倍，而且效果很好。我不确定这是最好的工作流程，因为在提交后很容易忘记推送，每次提交后都不必推送;当你想要推动时你推。这是关于DVCS的一个大想法：Commit和Push是截然不同的！和3种方式的合并冲突可能会引起真正的麻烦。您是否经常使用相同的代码行？在我的5-6名程序员团队中，每天推/拉几次，每天最多几次，我不记得上次我必须手动解决合并冲突。当然不是在过去一两个月。我们可以使用更好的工作流程，因为我认为分布式VC的复杂性超过了目前的好处。也许您应该更详细地描述您的工作流程，因为我在典型的工作日遇到的集中版本控制的唯一复杂性可能是一个命令，并且好处是巨大的。只做一次“hg blame”比集中版本节省的时间比我全年输入的所有“hg push”更多！

踩什不

对于它的价值，我们是第一次与Mercurial合作的类似规模的团队，我们开始遇到同样的问题。我们坚持不懈，现在情况好多了。我认为大多数问题都发生在代码库很小并且人们都试图处理相同的事情时。现在它已经变得更加成熟，人们并没有非常依赖彼此的脚趾，巴黎也大大减少了。希望你把它分类！

要回复问题请先登录或注册

小团队的Mercurial Workflow

5 个回复

发起人

3_way_merge

问题状态

小团队的Mercurial Workflow

与内容相关的链接

5 个回复

发起人

3_way_merge

问题状态