使用 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更新
3. hg commit, hg Push

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

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

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 中也是一样的（这是事实并非如此）。