如果我理解正确的话(我在这方面远远不是专家)，它们基本上都有不同的哲学。我第一次使用mercurial有9个月。现在我用git表示6。

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

Git是一个基于时间的文件系统。它的目标是向文件系统添加另一个维度。大多数都有文件和文件夹，git增加了时间。作为一个风投公司，它的设计是一个副产品。

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

在git中，只有一个对象池和这些跟踪文件(分支/头)，它们决定哪组对象代表处于特定状态的文件树。当推或拉git只发送你正在推或拉的特定分支所需的对象，这是所有对象的一个小子集。

就git而言，不存在“1个项目”。你可以在同一个回购中有50个项目，git不会在意。每一个都可以在同一个回购和live fine中单独管理。

Hg的分支概念是主项目的分支或分支的分支等。Git没有这样的概念。git中的分支只是树的一个状态，git中的所有东西都是分支。哪个分支是正式的、当前的或最新的在git中没有意义。

我不知道这是否有意义。如果我能把hg画出来，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都有一个叫做“分支”的东西，但它们并不是完全相同的东西。当不同的repo之间存在冲突时，mercurial就会产生一个分支。git中的分支显然类似于hg中的克隆。但是克隆虽然可能会给出类似的行为，但绝对不相同。考虑我尝试这些在git和hg使用铬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的克隆其实和git-new-workdir是一样的。这两个都创建了一个全新的工作目录，几乎就像输入cp -r project project-clone一样。这与在git中创建一个新分支不同。它的重量要重得多。如果git在hg中有分支，我不知道它是什么。

我知道在某种程度上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中有一些方法可以使每一行而不是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甚至有命令来决定要将同一文件中的哪些特定行复制到舞台，这样您也可以将这些提交分开。你为什么要这么做?因为作为单独的提交，其他人只能提取他们想要的，或者如果有问题，他们可以只恢复有问题的提交。

在bitbucket.org的mercurial和github的git之间需要注意的一件事是，mercurial可以有尽可能多的私人存储库，但github你必须升级到付费帐户。所以，这就是为什么我选择使用mercurial的bitbucket。

如果你是一名Windows开发人员，正在寻找基本的断开连接的版本控制，那么使用Hg。我发现Git难以理解，而Hg很简单，与Windows shell集成得很好。我下载了Hg，并遵循了这个教程(hginit.com) -十分钟后，我有了一个本地回购，并重新开始我的项目。

去年的某个时候，我评估了git和hg供我自己使用，并决定使用hg。我觉得它看起来是一个更干净的解决方案，并且在更多的平台上工作得更好。不过，这基本上是一个未知数。

最近，我开始使用git，因为git-svn和充当Subversion客户端的能力。这征服了我，现在我完全换成了git。我认为它的学习曲线略高(特别是当你需要探究内部时)，但它确实是一个很棒的系统。我要去读约翰发表的那两篇比较文章。

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

“Git是韦斯利·斯奈普斯。Mercurial是丹泽尔·华盛顿

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

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