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

Git非常注重改变这个历史图(以及由此产生的所有后果)，而Mercurial不鼓励重写历史，但这很容易做到，而且这样做的后果正是您应该期望的(也就是说，如果我修改了您已经拥有的变更集，如果您从我这里提取，您的客户端将会认为它是新的)。所以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文件:它是一个shell脚本，生成一个Ruby脚本，我认为它运行一个web服务器。shell脚本生成另一个shell脚本来启动第一个Ruby脚本。此外，还有一些Perl代码。

我喜欢将Mercurial和Git与James Bond和MacGyver进行比较的博客文章——Mercurial在某种程度上比Git更低调。在我看来，使用Mercurial的人并没有那么容易被打动。这反映在每个系统如何完成Linus所描述的“最酷的合并!”在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拉取的——force标志，这是必需的，因为当您从不相关的存储库进行拉取时，Mercurial将中止。正是这样的差异使Mercurial在我看来更加优雅。

在versioncontrolblog上有一个动态比较图表，你可以比较几种不同的版本控制系统。

这是git, hg和bzr之间的对比表。

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

这在实践中意味着什么?在git中，很多操作都更快，比如切换到另一个提交，比较提交等等。特别是当这些提交距离很远的时候。

说真的，mercurial的方法没有任何优势。

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

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

简而言之，Mercurial中的每个分支都需要自己的目录;在git中，你通常在单个目录下工作。 在Mercurial中切换分支意味着更改目录;在git中，这意味着要求git通过git checkout更改目录的内容。

老实说:我不知道是否可以用Mercurial做同样的事情，但因为我通常在web项目上工作，总是使用相同的目录和git对我来说似乎更舒服，因为我不需要重新配置Apache并重新启动它，而且每次分支时我都不会弄乱我的文件系统。

Edit: As Deestan noted, Hg has named branches, which can be stored in a single repository and allow the developer to switch branches within the same working copy. git branches are not exactly the same as Mercurial named branches, anyway: they are permanent and not throw away branches, like in git. That means that if you use a named branch for experimental tasks even if you decide to never merge it it will be stored in the repository. That's the reason why Hg encourages to use clones for experimental, short-running tasks and named branches for long-running tasks, like for release branches.

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

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

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

如果您对Mercurial和Git的性能比较感兴趣，请参阅本文。结论是:

Git和Mercurial都取得了不错的成绩，但在速度和存储库大小之间进行了有趣的权衡。Mercurial在添加和修改方面都非常快速，同时还能控制存储库的增长。Git也很快，但它的存储库在修改文件后增长非常快，直到重新打包——而这些重新打包可能非常慢。但是打包的存储库比Mercurial的要小得多。

如果从SVN迁移，请使用Mercurial，因为它的语法对SVN用户来说更容易理解。除此之外，任何一种选择都不会错。但是在选择之前一定要检查GIT教程和HGinit。