Question

在使用Mercurial时，我想了解您应该使用以下哪个例程，或者哪个例程更合适。假设我有最新的代码第一个例程如下：

第二是：

据我所知，第一个替代方案是大多数开发人员（应该）使用的方案，因为与第二个使用选项不同，它提供了使用本地存储库的机会，因为它是一个DVCS是正常的事情。

我的同事们鼓励我使用第二种方式，因为这样我避免了分支以及后来可能出现的合并问题（因为在过去，某种程度上，他们有这样的问题），所以我留在主干开发线上。我想第一个选项是应该更好的选项，因为合并是DVCS中不应该害怕的东西，与CVCS不同，它让我有机会使用本地存储库。

Answer 1

在这两种情况下你将要做的工作没有任何区别：

由于您正在处理已经承诺的工作，因此第一个工作流程对许多人来说更安全。这意味着如果合并变得复杂，那么回到干净状态是微不足道的：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]

你得到一个rebase

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

其中x'到z'是x到z的重新定义版本（不同的变更集ID，因为它们有不同的祖先）。

我一直使用这样的rebase，我觉得它给出了最好的整体历史。请记住不要重新定义已经公开的变更集：rebasing会修改变更集，但如果变更集已经公开，那么您很难修改其他副本。结果是重复的变更集和混淆。

Answer 2

基本上，您已经自己回答了问题：

第一个例程是DVCS的“默认”例程，因为它利用了典型的DVCS功能（本地存储库，更快的提交，因为没有涉及网络，更详细的历史记录，因为许多小提交与少数大提交......）

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

长期使用CVCS的用户（可能是您的同事）通常更喜欢第二种例行程序，因为这样他们已经知道的更多了。
此外，合并在DVCS中比CVCS更好，因此它们“可能出现合并问题”的争论可能仅仅是因为他们过去在CVCS 中遇到了问题并认为它在DVCS中是相同的（这是不是这样的。）