使用Mercurial时的替代例程Hg

Question

在使用Mercurial时，我想就您应该使用哪种下面的例程或者哪些更适合使用这些例程。假设我有最新的代码。
首先程序如下：

1. 做，如果
2. hg commit
3. 重复步骤1和2需要我的工作
4. 当我准备推我hg pull，hg update
5. hg merge，hg commit
6. hg push

二是：

1. 做我的工作
2. 当我准备好提交我hg pull，hg update
3. hg commit，hg push

的事情是，就我知道第一种选择是大多数开发人员（应该）使用的选择，因为与第二种选择不同，它提供了使用本地存储库，因为这对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，因为它们具有不同的祖先）的重定版本。

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

Answer 2

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

第一个例程是“默认”一个DVCS，因为它需要典型的DVCS的优势功能
（本地资源库，更快的承诺，因为没有网络参与，因为许多小的提交比较少的大提交更详细的历史...）

使用第二个例程不是“错误”或“不好”，但你必须意识到你使用的事实一个DVCS好像它是一个CVCS，所以你故意选择不使用DVCS的一些优点（见上文）。

长期CVCS用户（可能像你的同事）的人往往更喜欢第二个例程，因为他们感觉他们已经知道的更多。
另外，合并在DVCS中比CVCS更好地工作，所以他们的“可能的合并问题”参数可能仅仅是因为他们过去在CVCS中有问题，并且假定它在DVCS中是相同的（事实并非如此）。