我是一个三人团队的开发者，最近我们从CVS切换到了Mercurial。我们使用Mercurial通过在每个工作站上建立本地仓库，并将代码推送/拉取到开发服务器来进行版本控制。但我不确定这是否是最佳的工作流程，因为很容易忘记提交后进行推送操作，而且三方合并冲突可能会引起一些麻烦。请问是否有更好的工作流程可供选择？因为我认为分布式版本控制的复杂性已经超过了其所带来的好处。
谢谢！
小团队使用Mercurial的工作流程
13
- Tarski
2
1你对CVS满意吗？如果是，为什么要转换到Mercurial呢？ - anon
1简短的回答是我创造了他。主要想法是我们可以拥有每个开发人员的版本控制，而不必在中央存储库中使用每个开发人员分支。开发人员完成工作后，可以将其更改推送到共享存储库。我们的持续集成服务器拉取此存储库的头部并构建我们的可分发工件。 - BenM
5个回答
10
如果你遇到了很多三方合并的问题，可能是因为你和团队成员所做的工作有太多重叠。Mercurial在处理合并方面非常出色，只要你们不编辑同一文件的相同行。如果可能的话，你可以更清晰地分配工作，并避免大型合并带来的一些麻烦。同时请注意，这仍然是CVS的问题，因为它在合并方面比Mercurial更差。
你不需要在每次提交后都进行推送。你的工作流程可能如下：
- 提交某个功能的一部分。 - 提交该功能的更多部分。 - 提交功能的最后一部分。 - 为愚蠢的错误提交错误修复。 - 将完整的功能推送到存储库。
在某种程度上，这看起来像Going Dark，但可以通过确保上述示例中的功能范围较小来缓解这种情况。
你不需要在每次提交后都进行推送。你的工作流程可能如下：
- 提交某个功能的一部分。 - 提交该功能的更多部分。 - 提交功能的最后一部分。 - 为愚蠢的错误提交错误修复。 - 将完整的功能推送到存储库。
在某种程度上，这看起来像Going Dark，但可以通过确保上述示例中的功能范围较小来缓解这种情况。
- TwentyMiles
1
1大多数合并冲突发生在两个开发人员向一个类添加新功能时，比如每个人都添加了一个方法，恰好位于相同的行号上，例如文件末尾。 - Tarski
8
忘掉你所知道的关于CVS的一切。Mercurial与之完全不同，即使有些命令感觉有点类似。
阅读http://hginit.com/。按照示例操作。
忘掉你所知道的关于CVS的一切。
我是认真的。这是最难的部分。学会信任你的工具。
- Aaron Digulla
2
我同意。说“很容易忘记推送”只是证明他们还没有完全接受这种工作流程。 - tghw
我会看一下，但你有没有遇到一些比较简短的资源？@tghw 这是来自hg秘密教派的说法吗？ - Tarski
3
看起来你们都在同一个分支上做出修改。这样做的不足之处是，每次提交几乎都需要合并彼此的更改。虽然手动解决冲突是可以接受的，但你不希望每次推送都这么做。以下是我建议的工作流程。想法是更多地使用分支，这样你就不需要频繁地合并到主分支。
1. 让每个开发人员在单独的分支中开发每个功能。这样做可以避免不断合并其他人的更改，并且不用担心在下一个人之前推送不完整的工作会“很难合并”。
2. 当一个功能完成并且如果更改似乎可以干净地应用（判断性的调用），将该功能分支直接合并到主分支中并删除该功能分支。
3. 如果一个功能落后于主分支（合并了多个功能），或者合并似乎很困难：
- 将主分支合并到功能分支中。 - 在与其他开发人员相隔离的环境中查找和修复任何错误。 - 假设该功能准备就绪，请将其合并到主分支中（注意：现在这个方向的合并定义上是干净的）。如果没有准备好，则可以继续开发。
1. 让每个开发人员在单独的分支中开发每个功能。这样做可以避免不断合并其他人的更改，并且不用担心在下一个人之前推送不完整的工作会“很难合并”。
2. 当一个功能完成并且如果更改似乎可以干净地应用（判断性的调用），将该功能分支直接合并到主分支中并删除该功能分支。
3. 如果一个功能落后于主分支（合并了多个功能），或者合并似乎很困难：
- 将主分支合并到功能分支中。 - 在与其他开发人员相隔离的环境中查找和修复任何错误。 - 假设该功能准备就绪，请将其合并到主分支中（注意：现在这个方向的合并定义上是干净的）。如果没有准备好，则可以继续开发。
- Andres Jaan Tack
1
我们使用Mercurial，每个工作站都有本地存储库，并推送/拉取到开发服务器上。听起来对我来说很好。我的团队大约是这个规模，它运行得很好。
我不确定这是否是最佳工作流程，因为很容易在提交后忘记推送，您不必在每次提交后都进行推送；您可以在想要推送时进行推送。这就是DVCS的重要思想：提交和推送是不同的！
3路合并冲突可能会引起真正的头痛。你经常在同一行代码上工作吗？在我的5-6名程序员团队中，每天推送/拉取几次，每天提交多达几十次，我记不得上一次手动解决合并冲突是什么时候了。肯定不是在过去的一个月或两个月内。
目前，分布式VC的复杂性超过了其益处，我们是否可以使用更好的工作流程？
也许你应该更详细地描述你的工作流程，因为在我典型的工作日里，相对于集中式版本控制，我遇到的唯一复杂性可能只有一个命令，而好处是巨大的。只需要执行一次“hg blame”比我整年输入所有“hg push”的时间都要省！
我不确定这是否是最佳工作流程，因为很容易在提交后忘记推送，您不必在每次提交后都进行推送；您可以在想要推送时进行推送。这就是DVCS的重要思想：提交和推送是不同的！
3路合并冲突可能会引起真正的头痛。你经常在同一行代码上工作吗？在我的5-6名程序员团队中，每天推送/拉取几次，每天提交多达几十次，我记不得上一次手动解决合并冲突是什么时候了。肯定不是在过去的一个月或两个月内。
目前，分布式VC的复杂性超过了其益处，我们是否可以使用更好的工作流程？
也许你应该更详细地描述你的工作流程，因为在我典型的工作日里，相对于集中式版本控制，我遇到的唯一复杂性可能只有一个命令，而好处是巨大的。只需要执行一次“hg blame”比我整年输入所有“hg push”的时间都要省！
- Ken
0
就我所知，我们是一个规模相似的团队，第一次使用Mercurial，并且我们也遇到了同样的问题。
我们坚持下去，现在情况已经显著改善。我认为大部分问题出现在代码库很小的时候，人们都试图在同一个东西上工作。现在它已经更加稳定，人们之间的干扰也减少了很多。
希望你能解决这个问题！
- Chris Roberts
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接