使用汞时的替代例程

Question

在使用Mercurial时，我想了解您对下列哪一个例程应该使用，或者哪个更可取的意见。假设我有最新的代码。

第一个例程如下：

如果需要的话，work

• hg commit

• Repeat

• 执行我的

步骤1和2，当我准备推动I hg pull，

• 时，

二是：

当我准备好提交我的工作时，hg update

• hg commit，hg push

，

1. ，

问题是，据我所知，第一种选择是大多数开发人员(应该)使用的，因为与使用的第二种选择不同，它提供了使用本地存储库的机会，因为这对于DVCS来说是一件正常的事情。

我的同事鼓励我使用第二种方式，因为这样我就避免了分支和以后可能出现的合并问题(因为过去，不知怎么的，他们有这样的问题)，所以我就停留在主干开发线上。我猜第一种选择应该更好，因为合并在DVCS中是不应该害怕的，与CVCS不同，它给了我使用本地存储库的机会。

Answer 1

在这两种情况下，您所做的工作并没有任何不同：

• 在第一个工作流中，您将在步骤5中进行合并。
• 与第二个工作流进行完全相同的合并，作为步骤2.

中更新的一部分。

对于许多人来说，第一个工作流更安全，因为您正在处理已经承诺的工作。这意味着，如果合并结果是复杂的：hg update -C .，那么回到干净状态是很简单的。

但是，即使使用第二个工作流，您也可以返回原始文件：hg resolve --all --tool internal:local将重新执行hg update启动的合并，并为所有文件选择原始版本。

真正的区别在于，第一个工作流更好地显示了实际发生的情况。使用该工作流，您可以以更小和更符合逻辑的步骤显示更改。当你的大学试图理解你做了什么(代码评论)和未来的调试(用hg bisect)时，这会有很大的帮助。

使用hg rebase，您可以充分利用这两个世界。这样你就可以进行小的、合乎逻辑的提交，最后将这些提交移到大学所做的工作之上。在这种情况下，不会有合并的变化--美好而丰富的线性历史。

所以，如果你有这段经历之后，拉：

... [a] --- [b] --- [x] --- [y] --- [z]
               \
                [d] --- [e]

如果您已经将x创建为z，那么正常的合并将创建此历史记录：

... [a] --- [b] --- [x] --- [y] --- [z]
               \                       \
                [d] --- [e] ----------- [f]

重新定位你就能得到

... [a] --- [b] --- [d] --- [e] --- [x'] --- [y'] --- [z']

其中，x'到z'是基于x到z的版本(不同的更改集ID，因为它们有不同的祖先)。

我一直都是这样使用重基的，我觉得它给了我最好的历史。请记住，不要重新设置已经公开的变更集:重基修改变更集，但如果变更集已经公开，那么您很难修改其他副本。结果是重复的变更集和混乱。

Answer 2

基本上，你自己已经回答了这个问题：

第一个例程是DVCS的“默认”例程，因为它利用了典型的DVCS功能。

(本地存储库，更快的提交是因为不涉及网络，更详细的历史是因为很多小的提交而很少有大的.)

使用第二个例程并不是“错误”或“坏”，但您必须意识到，您使用DVCS就像使用CVCS一样，因此您有意选择不使用DVCS的一些优点(参见上文)。

长期使用CVCS的人(可能就像你的同事)通常更喜欢第二个例程，因为这让他们感觉到了他们已经知道的更多了。

另外，合并在DVCS中比CVCS工作得更好，所以他们的“合并可能出现的问题”参数可能只是因为他们过去在CVCS中遇到了问题，并且假设在DVCS中也是一样的(事实并非如此)。