Question

本章就 Mercurial 的使用方法进行了说明，内容如下。

• 钩子功能的概述与活用方法
• 分支、合并以及消除冲突的方法
• GUI 客户端的介绍

另外，还对多人开发时的工作流程进行了说明，它对于防范冲突及运用上的不统一有着重要的意义。

如今，无论人多人少，Mercurial 等版本控制系统都是开发中必备的工具，能否用好版本控制系统已成为左右开发效率的一个重要因素。

专栏 Git 与 Mercurial 的区别

Git 是一种广受欢迎的分布式版本控制系统，与 Mercurial 齐名。因此，我们能看到很多 Git 与 Mercurial 的命令对照表，这就是为 Git 用户准备的 Mercurial 入门，或者是为 Mercurial 用户准备的 Git 入门。不过，如果让 Git 用户单纯根据命令对照表来使用 Mercurial，或者反过来让 Mercurial 用户根据对照表使用 Git，恐怕会是一种很危险的行为。

要知道，虽然 Git 和 Mercurial 同为分布式版本控制系统，但二者的模型并不相同。乍看上去，人们只要记住 Git 中的命令和 Mercurial 中的命令的差别，就能随便在二者间换着用了，然而即使有对照表，也无法改变它们不同的本质，所以对很多操作都是都会产生误解，这早晚会让我们栽跟头。举个例子更能说明 Git 和 Mercurial 模型间的差异，Mercurial 的版本库由提交对象的图表构成，而 Git 的版本库由提交对象的图表和引用构成。

这个差别最明显地体现在对分支的看法以及同步（push/pull）上。

Mercurial 的分支本质上是给提交对象的分支的根部命了名。严格说来，分支只不过是被命了名的各个提交对象的参数。但是，在我们给子分支新命名之前，子分支会继承父分支的名字，所以说它在给分支的根部命名。

相对地，Git 的分支是给提交对象的图表的最新端命了名。这是一个每次提交都会跟着最新端切换的引用。Git 的 fast-foward 合并其实就是这个表示分支的引用的切换，分支的删除其实就是引用的删除。因此，Mercurial 中既没有 fast-foward 合并也没有分支的删除（fast-foward 曾被导入过，但与 Git 的 fast-foward 合并仍是貌相似而质不同）。

如果把 push/pull 看作版本库的同步，那么版本库模型不同的理由将更加显而易见。Mercurial 的版本库是提交对象的图表，因此只需将提交对象图表的差别同步即可。push 操作中只需发送对方没有的那部分图表，pull 则只需获取自己没有的那部分图表。比如“删除历史”就无法同步。就算我们加上 -f 选项，最多也就是让历史受到污染（共享了多余的子图表） 。

Git 的版本库是提交对象的图表和引用，因此双方必须保持同步。切换引用的必要性致使 pull 需要伴随合并操作。如果不进行合并，该分支就将出现 remote 的和 local 的两个最新端。

但是 Git 的分支是给最新端命的名，这就要求一个分支只能有一个最新端。Git 的 pull 之所以必须以分支为单位，恐怕就是因为存在这样一个需主观意识判断的合并过程。push 无法进行主观意识判断，所以只有满足 fast-foward 合并（不需主观意识判断的合并）的情况下才允许 push。

在更改历史上也有显著差异。Git 在日常使用中充满了更改历史，所以习惯 Git 的人在用 Mercurial 时总会去找类似的操作。但是，此时直接按对照表操作会出现很大隐患。虽然 Git 和 Mercurial 中都有“更改历史”，但二者实际要做的事却完全不同。Git 是新建图表并将引用切换到最新端，所以在 GC 启动之前仍然保留着更改前的图表。这个图表我们只是看不到罢了，但仍可以通过 reflog 引用它。

相对地，Mercurial 是实际更改原有图表，即向图表添加新的子图表并删除旧的子图表。一个由图表的引用构成，一个由图表直接构成，这里，二者的差别非常显 著。正因为如此，Git 在更改失败时只需引用 reflog 寻找更改前的修订版（分支的最新端），将这个修订版设置为该分支的头即可完成恢复，但 Mercurial 就必须通过 bundle backup 恢复旧的子图表，然后用 strip 命令删除新的子图表。

可见，由于 Git 与 Mercurial 在模型方面存在差异，导致更改历史有着实质上的不同，更改历史失败后的恢复难度及安全性也都大相径庭。所以各位在用 M ercurial 更改历史时，建议先让保存原历史的选项有效，等确认更改无误后再通过 strip 命令删除旧的子图表。