我在一个由 3 名开发人员组成的团队中工作，我们最近从 CVS 切换到 Mercurial。我们通过在每个工作站上都有本地存储库并拉/推到开发服务器来使用 Mercurial。我不确定这是最好的工作流程，因为在提交后很容易忘记推送，并且 3 路合并冲突会导致真正的头痛。有没有更好的工作流程我们可以使用，因为我认为分布式 VC 的复杂性目前超过了好处。
谢谢
问问题
1858 次
5 回答
10
如果您遇到很多 3 路合并，可能是因为您和您的团队成员的工作重叠太多。Mercurial 非常擅长处理合并本身，只要你们不编辑文件的完全相同的行。如果可能的话，您可以更清楚地划分工作并避免大型合并带来的一些麻烦。另请注意，这仍然是 CVS 的一个问题，因为它在合并方面可能比 mercurial 更糟糕。
您也不需要在每次提交后推送。您的工作流程可能如下所示：
- 提交某些功能的一部分。
- 提交更多的一些功能。
- 提交功能的最后一部分。
- 为愚蠢的错误提交错误修复。
- 将完整功能推送到回购。
在某种程度上，这看起来像Going Dark，但可以通过确保上述示例中的功能范围较小来缓解这种情况。
于 2010-07-02T21:51:42.900 回答
8
忘记所有关于 CVS 的知识。即使某些命令感觉有些相似，Mercurial 也完全不同。
阅读http://hginit.com/。遵循示例。
忘记所有关于 CVS 的知识。
我是认真的。这是最难的部分。学会相信你的工具。
于 2010-07-02T13:48:06.603 回答
3
听起来你们都在对同一个分支进行更改。这具有令人不满意的副作用，即您在几乎每次提交时都在合并彼此的更改，这很好，除了手动干预冲突不是您每次推送时都想做的事情。
这是我建议的工作流程。这个想法是更多地使用分支，因此您需要较少地合并到主分支。
让每个开发人员在单独的分支中开发每个功能。这边走：
您避免不断合并其他人的更改，并且
您无需在下一个人之前推动未完成的工作，“难以合并”。
当一个特性“完成”并且更改看起来可以干净地应用（判断调用）时，将特性分支直接合并到主分支并删除特性分支。
如果一个特性落后于主分支（许多特性合并），或者如果合并看起来很困难：
将 master 合并到功能分支中。
查找并修复与其他开发人员满意隔离的任何错误。
假设该功能已准备就绪，请将其合并到 master 中（注意：现在这个方向的合并将按照定义是干净的）。如果没有，您可以继续开发。
于 2010-07-02T22:31:09.033 回答
1
我们通过在每个工作站上都有本地存储库并拉/推到开发服务器来使用 Mercurial。
这对我来说听起来不错。我的团队大约是两倍的规模，而且效果很好。
我不确定这是最好的工作流程，因为在提交后很容易忘记推送，
您不必在每次提交后都推送；你想推的时候推。这就是 DVCS 的重要理念：Commit 和 Push 是不同的！
和 3 路合并冲突会引起真正的头痛。
您是否经常使用相同的代码行？在我的 5-6 名程序员团队中，每天推/拉几次，每天提交多达几十次，我不记得上次我必须手动解决合并冲突是什么时候。当然不是在过去的一两个月内。
有没有更好的工作流程我们可以使用，因为我认为分布式 VC 的复杂性目前超过了好处。
也许您应该更详细地描述您的工作流程，因为我在典型工作日遇到的集中版本控制的唯一复杂性可能是一个命令，其好处是巨大的。只做一次“hg blame”比我一整年不得不输入的所有“hg push”节省了更多的时间！
于 2010-07-02T23:47:14.873 回答
0
值得一提的是，我们是第一次与 Mercurial 合作的规模相似的团队，我们从同样的问题开始。
我们坚持了下来，现在情况明显好转了。我认为大多数问题发生在代码库很小并且人们都在尝试做同一件事的时候。现在它已经有点成熟了，人们并没有那么多地踩对方的脚趾，巴黎也大大减少了。
希望你能把它整理好！
于 2012-06-28T21:13:31.557 回答