Mercurial 和 Git 有啥区别？

Posted 2023-02-16

【中文标题】Mercurial 和 Git 有啥区别？

【英文标题】：What is the Difference Between Mercurial and Git?Mercurial 和 Git 有什么区别？

【发布时间】：2010-09-07 08:12:57

【问题描述】：

我在 Windows（使用 msysGit）上使用 git 已经有一段时间了，我喜欢分布式源代码控制的想法。就在最近，我一直在看 Mercurial (hg)，它看起来很有趣。但是，我无法理解 hg 和 git 之间的差异。

有没有人在 git 和 hg 之间进行并排比较？我很想知道 hg 和 git 有什么不同，而不必参加***的讨论。

【参考方案1】：

这些文章可能会有所帮助：

Git vs. Mercurial: Please Relax（Git 是 MacGyver，Mercurial 是 James Bond） The Differences Between Mercurial and Git

编辑：将 Git 和 Mercurial 与名人进行比较似乎是一种趋势。还有一个：

Git is Wesley Snipes, Mercurial is Denzel Washington

【讨论】：

“Git vs Mercurial Please Relax”已经严重过时了，尽管它和这个问题一样古老。既然这两个工具都添加了 3 年以上的功能，也许应该删除并重新打开这个问题。

【参考方案2】：

我在 Mercurial 上工作，但基本上我相信这两个系统是等效的。它们都使用相同的抽象：构成历史的一系列快照（变更集）。每个变更集都知道它来自哪里（父变更集）并且可以有许多子变更集。最近的 hg-git 扩展在 Mercurial 和 Git 之间提供了双向桥梁，并在某种程度上说明了这一点。

Git 非常注重改变这个历史图表（以及随之而来的所有后果），而 Mercurial 不鼓励重写历史，but it's easy to do anyway 这样做的后果正是您应该期望的那样（即，如果我修改了您已经拥有的变更集，如果您从我这里拉出，您的客户会将其视为新的）。所以 Mercurial 对非破坏性命令有偏见。

至于轻量级分支，Mercurial 支持具有多个分支的存储库，因为...，我一直认为。具有多个分支的 Git 存储库正是这样：在一个存储库中的多个不同的开发链。 Git 然后将名称添加到这些链中，并允许您远程查询这些名称。 Mercurial 的 Bookmarks 扩展添加了本地名称，而在 Mercurial 1.6 中，您可以在推/拉时移动这些书签。

我使用 Linux，但显然 TortoiseHg 比 Windows 上的 Git 更快更好（由于更好地使用了糟糕的 Windows 文件系统）。 http://github.com 和 http://bitbucket.org 都提供在线托管，Bitbucket 的服务很棒而且响应迅速（我没有尝试过 github）。

我选择 Mercurial 是因为它给人一种干净优雅的感觉——我被使用 Git 获得的 shell/Perl/Ruby 脚本吓到了。如果您想知道我的意思，请尝试查看git-instaweb.sh file：它是一个生成 Ruby 脚本的 shell 脚本，我认为它运行一个网络服务器。 shell 脚本生成另一个 shell 脚本来启动第一个 Ruby 脚本。还有一点 Perl，很好衡量。

我喜欢将 Mercurial 和 Git 与 James Bond 和 MacGyver 进行比较的 blog post——Mercurial 在某种程度上比 Git 低调。在我看来，使用 Mercurial 的人并没有那么容易留下深刻印象。这反映在每个系统如何执行 Linus 所描述的 "the coolest merge EVER!"。在 Git 中，您可以通过以下方式与不相关的存储库合并：

git fetch <project-to-union-merge>
GIT_INDEX_FILE=.git/tmp-index git-read-tree FETCH_HEAD
GIT_INDEX_FILE=.git/tmp-index git-checkout-cache -a -u
git-update-cache --add -- (GIT_INDEX_FILE=.git/tmp-index git-ls-files)
cp .git/FETCH_HEAD .git/MERGE_HEAD
git commit

这些命令在我看来相当神秘。在 Mercurial 中，我们这样做：

hg pull --force <project-to-union-merge>
hg merge
hg commit

请注意 Mercurial 命令是如何简单明了，一点也不特别——唯一不寻常的是 hg pull 的 --force 标志，这是必需的，因为当您从不相关的存储库中提取时，Mercurial 将中止。正是这样的差异让 Mercurial 在我看来更加优雅。

【讨论】：

请注意，TortoiseHg 还可以与 Linux 上的 Gnome 文件管理器 Nautilus 一起使用。

只有 httpd 是 Webrick，即 ruby​​ 网络服务器，才会生成 Ruby 脚本。

与 Git 一样，Mercurial 会在您提交时存储文件的快照。我不同意重命名只能通过像 Git 一样的启发式方法来跟踪，模型中没有任何内容阻止向快照添加额外信息，例如重命名信息。我们在 Mercurial 中这样做。

要将不相关的项目与 git 合并（拉取），您可以简单地执行以下操作：git pull <url-of-project>。您引用的邮件来自 git 的早期（2005 年）

knittl：啊，很好，我很高兴听到 Git 变得不那么神秘了。尽管如此，我认为这个示例显示了系统在我们认为它很酷方面的不同之处，并且与 Mercurial 相比，Git 对我来说感觉更底层（但不是更强大）。

【参考方案3】：

Git 是一个平台，Mercurial “只是”一个应用程序。 Git 是一个版本化的文件系统平台，它恰好附带一个 DVCS 应用程序，但与平台应用程序一样，它比专注的应用程序更复杂且边缘更粗糙。但这也意味着 git 的 VCS 非常灵活，您可以使用 git 做大量非源代码控制的事情。

这就是区别的本质。

最好从头开始理解 Git——从存储库格式开始。 Scott Chacon’s Git Talk 是一个很好的入门。如果你在不知道底层发生了什么的情况下尝试使用 git，你最终会感到困惑（除非你只坚持非常基本的功能）。当您想要的只是日常编程例程的 DVCS 时，这听起来可能很愚蠢，但 git 的天才之处在于存储库格式实际上非常简单，您可以很容易地理解 git 的整个操作。 p>

对于一些更注重技术性的比较，我个人看过的最好的文章是 Dustin Sallings 的：

The Differences Between Mercurial and Git Reddit thread where git-experienced Dustin answers his own git neophyte questions

他实际上已经广泛使用了这两种 DVCS，并且对它们都非常了解——最终他更喜欢 git。

【讨论】：

我经常读到人们提到 git 是一个“平台”，但这更多的是一种理论或普遍的神话，因为除了运行 git 之外，没有其他重要的例子可以证明它是一个平台。

@Ian - 如果我没记错的话，Aptana Studio 3 将它用于其内部更新系统。

所以，简而言之：Mercurial 是一个开源的分布式修订控制系统，而 git 是一种生活方式的选择。

【参考方案4】：

最大的区别在于 Windows。 Mercurial 是本机支持的，Git 不支持。您可以使用bitbucket.org 获得与github.com 非常相似的托管（实际上，当您获得免费的私人存储库时更好）。我使用 msysGit 有一段时间了，但后来改用 Mercurial 并且对它非常满意。

【讨论】：

所以“natively”这个词并不完全正确，但它在 windows 下并没有得到很好的支持，这是肯定的。

git 在 Windows 上得到一定程度的支持。但是尝试跨平台使用 Unicode 文件名，看看你会遇到什么痛苦。

@Craig：这更多是平台的缺点。一个称职的平台将允许您切换到合适的语言环境。如果你坚持使用 utf-8，除了 Mac OS X 对 utf-8 的规范化略有不同之外，你会很好，但是，我不确定 Windows 是否甚至允许你使用 utf-8...

Windows 支持 Unicode，尽管 MS 在其 API 中选择使用 UTF-16 而不是 UTF-8。尽管如此，git 很有可能支持 Unicode 跨平台。 SVN 很好地解决了这个问题。但目前它并不是 msysGit 开发的高优先级。 code.google.com/p/msysgit/issues/detail?id=80

【参考方案5】：

如果您是寻找基本断开连接的修订控制的 Windows 开发人员，请选择 Hg。我发现 Git 难以理解，而 Hg 很简单并且与 Windows shell 很好地集成在一起。我下载了 Hg 并关注了 this tutorial (hginit.com) - 十分钟后，我有了一个本地 repo 并重新开始我的项目。

【讨论】：

我遵循了相同的教程。这是确定的。

【参考方案6】：

我认为关于“Mercurial vs. Git”的最佳描述是：

"Git is Wesley Snipes. Mercurial is Denzel Washington"

【讨论】：

这应该有什么帮助？这是否意味着git更像是武侠类型？

【参考方案7】：

它们几乎相同。 从我的角度来看，最重要的区别（我的意思是，让我选择一个 DVCS 而不是另一个的原因）是这两个程序如何管理分支。

要使用 Mercurial 启动新分支，您只需将存储库克隆到另一个目录并开始开发。然后，您拉动并合并。 使用 git，您必须明确地为要使用的新主题分支命名，然后开始编码使用同一目录。

简而言之，Mercurial 中的每个分支都需要自己的目录；在 git 中，您通常在单个目录中工作。 在 Mercurial 中切换分支意味着更改目录；在 git 中，意思是让 git 用 git checkout 来改变目录的内容。

老实说：我不知道是否可以对 Mercurial 做同样的事情，但由于我通常从事 Web 项目，因此始终使用与 git 相同的目录对我来说似乎很舒服，因为我不必须重新配置 Apache 并重新启动它，而且我每次分支时都不会弄乱我的文件系统。

编辑：正如 Deestan 所说，Hg 具有命名分支，可以存储在单个存储库中，并允许开发人员在同一个工作副本中切换分支。无论如何，git 分支与 Mercurial 命名分支并不完全相同：它们是永久性的，不会像 git 中那样丢弃分支。这意味着如果您将命名分支用于实验任务，即使您决定永远不合并它，它也会存储在存储库中。这就是为什么 Hg 鼓励将克隆用于实验性、短期运行的任务，并将命名分支用于长期运行的任务，例如发布分支。

许多 Hg 用户更喜欢克隆而不是命名分支的原因更多是社会或文化而不是技术。例如，在 Hg 的最新版本中，甚至可以关闭命名分支并递归地从变更集中删除元数据。

另一方面，git 邀请使用“命名分支”，这些分支不是永久性的，也不会作为元数据存储在每个变更集上。

那么，从我个人的角度来看，git的模型与命名分支的概念有很深的联系，并且在一个分支和另一个具有相同目录的分支之间切换； hg 可以对命名分支做同样的事情，但它鼓励使用克隆，我个人不太喜欢。

【讨论】：

这没有区别； Hg 也命名了分支。我们在正常开发过程中一直使用它们，而不是克隆分支。

AFAIK，Hg中的命名分支是在每次提交中存储元数据的；我可能错了，但我读到一旦你创建了一个分支，它的元数据就会嵌入到每个变更集中并成为历史的一部分。这与 git 有很大的不同。 “克隆非常适合您不想记录分支名称的快速实验，而命名分支则适合长期分支”tinyurl.com/2wz39qx 我在帖子中想说的是 git 的标准工作流程邀请您使用一个工作副本； Hg 标准工作流程包括不符合我个人需求的克隆。

关于相似点/差异的一个很好的解释：Git & Hg 中的分支，请参阅：mercurial.selenic.com/wiki/GitConcepts#Branch_model

hg 中的命名分支与 git 中的分支完全不同。在 hg 中，有一个 true 路径。所有分支都是该路径的分支。在 git 中没有一条真正的路径。只是回购的不同状态和指向该状态的指针。每个分支只是一个不同的指针。哪个指针是主要的要使用。分支都是对等的。

【参考方案8】：

git 和 mercurial 之间有一个巨大的区别；代表每个提交的方式。 git 将提交表示为快照，而 mercurial 将它们表示为差异。

这在实践中意味着什么？好吧，在 git 中很多操作更快，例如切换到另一个提交、比较提交等。特别是如果这些提交距离很远。

据我所知，mercurial 的方法没有任何优势。

【讨论】：

变更集（diffs）的优势在于占用更少的空间。 Git 通过使用压缩来恢复用于提交的空间，但这需要偶尔进行显式重新压缩步骤（“git pack”）。

现在叫'git gc'，但是垃圾回收有不同的级别，有些级别在最近的git版本中是自动执行的。

实际上 mercurial 也使用快照

我无法理解您在“快照”和“差异”之间的区别。 hg 和 git store 都作为（组）文件 deltas 提交。这些增量基于各个 SCM 选择的任何先前版本。你有没有数字表明 git 对于你提到的操作实际上更快？更新到另一个提交花费大部分时间写入工作目录，而不是阅读 repo。

'Snapshot's vs. 'diff's - 完全不相关。但是，存储在内部的存储库与用户看到的内容无关。 git 和 mercurial 都向用户呈现“快照”。没有理由不能将与 git 相同的存储库格式添加到 mercurial，就像我相信 Bazaar 所做的那样。

【参考方案9】：

什么都没有。他们都做同样的事情，都表现得差不多。你应该选择一个而不是另一个的唯一原因是如果你帮助一个已经使用一个的项目..

另一个可能的原因是应用程序或服务只支持其中一个系统。例如，我几乎选择学习 git 是因为github..

【讨论】：

看来你的回答太务实了。 :)

【参考方案10】：

还有google的对比（虽然有点老，2008年做的）

http://code.google.com/p/support/wiki/DVCSAnalysis

【参考方案11】：

如果我对它们的理解正确（而且我远不是这方面的专家），它们基本上都有不同的哲学。我第一次使用 mercurial 9 个月。现在我已经用 git 了 6 次了。

hg 是版本控制软件。它的主要目标是跟踪软件的版本。

git 是一个基于时间的文件系统。它的目标是为文件系统添加另一个维度。大多数都有文件和文件夹，git增加了时间。作为 VCS，它的工作效果非常棒，这是其设计的副产品。

在 hg 中，它始终试图维护整个项目的历史。默认情况下，我相信 hg 在推拉时希望所有用户对所有对象进行所有更改。

在 git 中只有一个对象池和这些跟踪文件（分支/头），它们确定哪些对象集代表处于特定状态的文件树。推或拉时，git 仅发送您正在推或拉的特定分支所需的对象，这是所有对象的一小部分。

就 git 而言，没有“1 个项目”。你可以在同一个仓库中拥有 50 个项目，而 git 不会在意。每个都可以在同一个 repo 中单独管理，并且可以正常运行。

Hg 的分支概念是从主项目分支或从分支分支等。Git 没有这样的概念。 git 中的一个分支只是树的一个状态，一切都是 git 中的一个分支。哪个分支是官方的、当前的或最新的在 git 中没有任何意义。

我不知道这是否有意义。如果我可以画图，hg 可能看起来像这样，其中每个提交都是 o

             o---o---o
            /        
o---o---o---o---o---o---o---o
         \         /
          o---o---o

一棵树，只有一个根和树枝。虽然 git 可以做到这一点，而且人们经常以这种方式使用它，但并没有强制执行。一个git图片，如果有这种东西，很容易变成这样的

o---o---o---o---o

o---o---o---o
         \
          o---o

o---o---o---o

事实上，在某些方面，在 git 中显示分支甚至没有意义。

讨论时非常混乱的一件事，git 和 mercurial 都有一个叫做“分支”的东西，但它们并不是完全一样的东西。当不同的 repos 之间存在冲突时，就会出现 mercurial 的一个分支。 git 中的分支显然类似于 hg 中的克隆。但是一个克隆，虽然它可能会给出类似的行为，但绝对是不一样的。考虑我在 git vs hg 中使用相当大的 chromium repo 尝试这些。

$ time git checkout -b some-new-branch
Switched to new branch 'some-new-branch'

real   0m1.759s
user   0m1.596s
sys    0m0.144s

现在在 hg 中使用克隆

$ time hg clone project/ some-clone/

updating to branch default
29387 files updated, 0 files merged, 0 files removed, 0 files unresolved.
real   0m58.196s
user   0m19.901s
sys    0m8.957

这两个都是热运行。即，我运行它们两次，这是第二次运行。 hg clone 实际上与 git-new-workdir 相同。这两个都创建了一个全新的工作目录，几乎就像您输入了cp -r project project-clone。这与在 git 中创建新分支不同。它的重量要重得多。如果在 hg 中有真正的 git 分支，我不知道它是什么。

我在某种程度上理解 hg 和 git 可能能够做类似的事情。如果是这样，那么他们引导您进入的工作流程仍然存在巨大差异。在 git 中，典型的工作流程是为每个特性创建一个分支。

git checkout master
git checkout -b add-2nd-joypad-support
git checkout master
git checkout -b fix-game-save-bug
git checkout master
git checkout -b add-a-star-support

刚刚创建了 3 个分支，每个分支都基于一个名为 master 的分支。 （我确信在 git 中有某种方法可以使这些 1 行而不是 2 行）

现在开始做我刚做的一个

git checkout fix-game-save-bug

然后开始工作。提交事情等。即使在像 chrome 这样大的项目中，在分支之间切换也几乎是瞬时的。我实际上不知道如何在 hg 中做到这一点。这不是我读过的任何教程的一部分。

另一个很大的不同。 Git 的舞台。

Git 有这个阶段的想法。您可以将其视为隐藏文件夹。当您提交时，您只提交舞台上的内容，而不是工作树中的更改。这听起来可能很奇怪。如果您想提交工作树中的所有更改，您可以使用 git commit -a 将所有修改后的文件添加到阶段，然后提交它们。

那么舞台的意义何在？您可以轻松地分离您的提交。想象一下，你编辑了 joypad.cpp 和 gamesave.cpp，你想分别提交它们

git add joypad.cpp  // copies to stage
git commit -m "added 2nd joypad support"
git add gamesave.cpp  // copies to stage
git commit -m "fixed game save bug"

Git 甚至有命令来决定您要将同一文件中的哪些特定行复制到阶段，这样您也可以单独拆分这些提交。你为什么想这么做？因为作为单独的提交，其他人只能提取他们想要的提交，或者如果有问题，他们可以只恢复有问题的提交。

【讨论】：

“Git 甚至有命令来决定你想将同一文件中的哪些特定行复制到阶段，这样你也可以单独拆分这些提交。”这些命令是什么？

@James:git add --patch，见linux.die.net/man/1/git-add或使用git add -i，如***.com/questions/2372583/…

@gman: 你可以直接使用git branch <name> 来创建一个新分支，而不是用checkout -b <name> 签出master 和分支

【参考方案12】：

版本控制博客上有一个动态比较图表，您可以在其中比较几个不同的版本控制系统。

Here is a comparison table between git, hg and bzr.

【讨论】：

Mercurial 的信息并不完全准确：Mercurial 确实有“移动或重命名后的智能合并”。具体来说，这意味着如果我将dir-a/foo.c 重命名为dir-b/foo.c 并继续处理dir-b/foo.c，那么您在dir-a/foo.c 上的工作将在拉取后正确地与我的工作合并。

关于 Git 的信息（来自Better SCM Initiative 比较，IIRC）在一些地方也是不准确甚至无效的。

【参考方案13】：

在与分支机构合作（尤其是短期分支机构）方面存在很大差异。

在将 Mercurial 与 Git 进行比较的 this article (BranchingExplained) 中有解释。

【参考方案14】：

您的项目中是否有任何基于 Windows 的合作者？

因为如果有的话，Git-for-Windows GUI 看起来很笨拙、困难、不友好。

相比之下，Mercurial-on-Windows 就很简单了。

【讨论】：

我喜欢git，但这里我必须同意。 Git 有一个更好的命令行和更好的文档。我很乐意将 git 命令与 posix shell 一起使用。但是 windows 上的 tortoiseHG 很棒，它甚至集成了几个 diff 工具（无法比较），并且完全支持 sub-repos，以及许多 hg 插件，如 strip/mq

至少有一个非常好的 Windows（和 OS X + Linux）Git GUI 可用。

【参考方案15】：

在 bitbucket.org 的 mercurial 和 github 的 git 之间需要注意的一点是，mercurial 可以拥有任意数量的私有存储库，但是 github 你必须升级到付费帐户。所以，这就是我选择使用 mercurial 的 bitbucket 的原因。

【参考方案16】：

去年的某个时候，我为自己的使用评估了 git 和 hg，并决定使用 hg。我觉得它看起来像一个更清洁的解决方案，并且当时在更多平台上运行得更好。不过，这主要是一次折腾。

最近，由于 git-svn 和充当 Subversion 客户端的能力，我开始使用 git。这赢得了我的支持，我现在已经完全切换到 git。我认为它的学习曲线略高（特别是如果你需要探索内部），但它确实是一个很棒的系统。我要去阅读约翰现在发布的那两篇比较文章。

【讨论】：

看看hgsubversion：bitbucket.org/durin42/hgsubversion。它目前需要 Mercurial 的开发版本，但他们将在 7 月 1 日发布 Mercurial 1.3 版本。

【参考方案17】：

我目前正处于从 SVN 迁移到 DVCS 的过程中（同时在博客上讲述我的发现，我的第一次真正的博客工作......），并且我做了一些研究（=谷歌搜索）。据我所知，你可以用这两个包做大部分事情。看起来 git 有更多或更好的实现高级功能， 我确实觉得与 windows 的集成对于 mercurial 和 TortoiseHg 来说更好一些。我知道还有 Git Cheetah（我两种都试过了），但是这种反复无常的解决方案感觉更健壮。

看看它们都是开源的（对吗？）我认为它们都不会缺少重要的功能。如果某件事很重要，人们会要求它，人们会对其进行编码。

我认为对于常见的做法，Git 和 Mercurial 绰绰有余。他们都有使用它们的大项目（Git -> linux 内核，Mercurial -> Mozilla 基金会项目，当然还有其他），所以我认为两者都没有真正缺乏什么。

话虽如此，我对其他人对此的看法很感兴趣，因为它会成为我写博客的重要来源；-)

【讨论】：

是的，它们都是开源项目。

【参考方案18】：

InfoQ's guide about DVCS 上提供了关于 git、Mercurial 和 Bazaar 的出色而详尽的比较表和图表。

【参考方案19】：

我意识到这不是答案的一部分，但在这一点上，我还认为 NetBeans 和 Eclipse 等平台的稳定插件的可用性在该工具更适合该任务方面发挥了作用，或者更确切地说，哪个工具最适合“你”。也就是说，除非您真的想要通过 CLI 方式进行操作。

Eclipse（以及基于它的所有东西）和 NetBeans 有时都会在远程文件系统（例如 SSH）和文件的外部更新方面出现问题；这也是为什么您希望您选择“无缝”工作的另一个原因。

我现在也在尝试为自己回答这个问题 .. 我已经将候选者归结为 Git 或 Mercurial .. 感谢大家在不信教的情况下就该主题提供有用的意见。

【讨论】：

+1，因为“无缝”体验比不使用这些东西的人认为的更重要。一个可靠的 IDE 插件会带来很大的不同。

【参考方案20】：

mercurial 和 git 的另一个有趣的比较：Mercurial vs Git。 主要关注内部结构及其对分支过程的影响。

【参考方案21】：

如果您对 Mercurial 和 Git 的性能比较感兴趣，请查看 this article。结论是：

Git 和 Mercurial 都取得了不错的成绩，但在速度和存储库大小之间做出了有趣的权衡。 Mercurial 的添加和修改速度都很快，同时可以控制存储库的增长。 Git 也很快，但在您重新打包之前，它的存储库会随着修改过的文件快速增长——而这些重新打包可能会非常慢。但是打包后的存储库比 Mercurial 的要小得多。

【参考方案22】：

mercurial 网站在两个系统之间有一个great description of the similarities and differences，解释了词汇和底层概念的差异。作为一个长期使用 git 的用户，它确实帮助我理解了 Mercurial 的心态。

【参考方案23】：

如果您从 SVN 迁移，请使用 Mercurial，因为它的语法对于 SVN 用户来说更容易理解。除此之外，你也不会出错。但请在选择其中一个之前检查GIT tutorial 和HGinit。

【参考方案24】：

此链接可以帮助您了解区别 http://www.techtatva.com/2010/09/git-mercurial-and-bazaar-a-comparison/

【参考方案25】：

有些人认为 VCS 系统必须很复杂。他们鼓励在该领域发明术语和概念。他们可能会认为许多关于这个主题的博士会很有趣。其中可能是设计 Git 的人。

Mercurial 的设计理念不同。开发人员不应该太关心 VCS，而应该把时间花在他们的主要功能上：软件工程。 Mercurial 允许用户使用并愉快地滥用系统，而不会让他们犯任何不可恢复的错误。

任何专业工具都必须带有设计清晰且直观的 C​​LI。 Mercurial 用户可以通过发出没有任何奇怪选项的简单命令来完成大部分工作。在 Git 双破折号中，疯狂的选项是常态。如果您是 CLI 人员（老实说，任何有自尊的软件工程师都应该如此），Mercurial 具有很大的优势。

举个例子，假设你错误地做了一个提交。您忘记编辑一些文件。要撤消您在 Mercurial 中的操作，您只需键入：

$ hg rollback

然后您会收到一条消息，提示系统撤消您的最后一笔交易。

在 Git 中你必须输入：

$ git reset --soft HEAD^

好吧，假设您知道什么是重置。但除此之外，您还必须知道“--soft”和“--hard”重置是什么（任何直观的猜测？）。哦，当然不要忘记最后的 '^' 字符！ （现在里奇的名字是……）

Mercurial 与第三方工具（如 kdiff3 和 meld）的集成也更好。生成你的补丁合并你的分支，而不用大惊小怪。 Mercurial 还包括一个简单的 http 服务器，您可以通过键入

来激活它

hg serve

并让其他人浏览您的存储库。

底线是，Git 做 Mercurial 所做的事情，但方式要复杂得多，而且 CLI 也差很多。如果您想将项目的 VCS 转变为科学研究领域，请使用 Git。如果您想在不关心 VCS 工作的情况下完成它，并专注于您的实际任务，请使用 Mercurial。

【讨论】：

其实你可以alias commands in git，这使得CLI使用起来不那么复杂。这个SuperUser (StackExchange) question里面有一堆。

确实如此，您还可以编写 shell 脚本来处理一些常见任务。最终，您开始意识到您正在构建一个包装 CLI 来处理具有设计不良且违反直觉的 CLI 的 VCS。不仅如此。 Git 引入了一大堆可用性有问题的概念，用户最终不得不学习和理解这些概念，以便对文档和 CLI 消息感到满意。