version-control - 使用 Mercurial Hg 时的替代例程

Question

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

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

第二个是:

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

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

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

Answer 1

在这两种情况下，您将要做的工作没有任何区别:

• 对于第一个工作流程，您将在第 5 步中进行 merge 。

• 在第二个工作流中，您执行与步骤 2 中更新的一部分完全相同的 merge 。

第一个工作流程对许多人来说感觉更安全，因为您正在处理已经提交的工作。这意味着如果 merge 变得很复杂，回到干净状态是微不足道的:hg update -C .。

但实际上，即使使用第二个工作流程，您也可以取回原始文件:hg resolve --all --tool internal:local 将重做 hg update 的 merge 启动并为所有文件选择原始版本。

真正的区别在于第一个工作流程更好地展示了实际发生的事情。使用该工作流程，您可以以更小、更合乎逻辑的步骤展示您的更改。当您的大学试图了解您所做的事情(代码审查)以及 future 的调试(使用 hg bisect)时，这会很有帮助。

您可以使用 hg rebase 两全其美。这让你可以做出小而合乎逻辑的 promise ，然后最终将这些 promise 转移到你的大学所做的工作之上。在那种情况下不会有 merge 变更集——很好且丰富的线性历史。

因此，如果您在拉取后有此历史记录:

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

您在其中创建了 x 到 z，然后正常 merge 将创建此历史记录:

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

通过 rebase 你得到

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

其中 x' 到 z' 是 x 到 z 的 rebase 版本(不同的变更集 ID，因为他们有不同的祖先)。

我一直都这样使用 rebase ，我觉得它提供了最好的整体历史记录。请记住不要对已经公开的变更集进行 rebase : rebase 会修改变更集，但是如果变更集已经公开，那么您就很难修改其他副本。结果是重复的变更集和困惑。