Answers:
这些文章可能会帮助：
编辑：比较Git和Mercurial与名人似乎是一种趋势。还有一个：
我从事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提供在线托管，在到位桶的服务是伟大的，响应的（我没有尝试过的github）。
我选择Mercurial是因为它干净利落-我对Git附带的shell / Perl / Ruby脚本不满意。如果您想了解我的意思，请尝试看一下该git-instaweb.sh文件：这是一个生成Ruby脚本的Shell脚本，我认为该脚本运行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命令是普通命令，而不是特殊命令-唯一不寻常的是--force标志hg pull，这是必需的，因为从不相关的存储库中提取时Mercurial将会中止。正是这种差异使Mercurial在我看来更加优雅。
git pull <url-of-project>。你报的邮件是从混帐的非常初期（2005年）
Git是一个平台，Mercurial是“仅”一个应用程序。Git是一个版本化的文件系统平台，刚好随附了DVCS应用程序，但与平台应用程序一样，它比集中应用程序更复杂且边缘更粗糙。但这也意味着git的VCS非常灵活，并且您可以使用git进行大量的非源代码控制。
这就是差异的本质。
从根本上最好地了解Git –从存储库格式开始。Scott Chacon的Git Talk是对此的出色入门。如果您尝试使用git而不了解幕后发生的事情，那么您最终会在某些时候感到困惑（除非您仅坚持非常基本的功能）。当您想要的只是日常编程例程的DVCS时，这听起来可能很愚蠢，但是git的天才之处在于，存储库格式实际上非常简单，您可以很容易地理解git的整个操作。
对于一些更注重技术性的比较，我个人看到的最好的文章是Dustin Sallings的文章：
他实际上已经广泛使用了这两种DVCS，并且对它们都了解得很深-最终更喜欢git。
最大的区别在于Windows。Mercurial本身受支持，而Git则不受支持。您可以使用bitbucket.org获得与github.com非常相似的托管服务（实际上，获得免费的私有存储库甚至更好）。我使用msysGit已有一段时间，但后来搬到Mercurial并对此感到非常满意。
如果您是Windows开发人员，正在寻找基本的脱机版本控制，请使用Hg。我发现Git难以理解，而Hg很简单，并且与Windows Shell很好地集成在一起。我下载了Hg，并按照了本教程（hginit.com）的操作 -十分钟后，我有了一个本地存储库，然后又可以开始进行我的项目了。
它们几乎是相同的。从我的角度来看（最重要的区别是，我选择一个DVCS而不是另一个DVCS的原因）是这两个程序如何管理分支。
要使用Mercurial启动新分支，只需将存储库克隆到另一个目录并开始开发。然后，您将合并。使用git时，您必须为要使用的新主题分支明确命名，然后使用同一目录开始编码。
简而言之，Mercurial中的每个分支都需要有自己的目录。在git中，您通常在单个目录中工作。在Mercurial中切换分支意味着更改目录。在git中，这意味着要求git使用git checkout更改目录的内容。
老实说：我不知道是否可以对Mercurial进行同样的操作，但是由于我通常在Web项目上工作，因此对git使用始终相同的目录似乎很方便，因为我不必重新启动-配置Apache并重新启动它，并且每次分支时都不会弄乱文件系统。
编辑：正如Deestan所指出的那样，Hg 命名为branch，可以将其存储在单个存储库中，并允许开发人员在同一工作副本内切换分支。git分支与Mercurial命名分支并不完全相同：它们是永久的，不会像git中那样丢弃分支。这意味着如果您将命名分支用于实验任务，即使您决定永远不合并它，也将存储在存储库中。这就是为什么Hg鼓励使用克隆来进行实验性的，短期运行的任务，并使用命名分支来处理长期运行的任务，例如发布分支。
许多Hg使用者偏爱克隆而不是命名分支的原因，其社会或文化意义远大于技术意义。例如，使用最新版本的Hg，甚至可以关闭命名分支并从变更集中递归删除元数据。
另一方面，git邀请使用“命名分支”，这些分支不是永久的，并且不会作为元数据存储在每个变更集上。
从我个人的角度来看，git的模型与命名分支的概念紧密相连，并在具有相同目录的分支和另一个分支之间进行切换。hg可以对命名分支执行相同的操作，但是它鼓励使用克隆，我个人不太喜欢克隆。
git和mercurial之间有一个巨大的区别；表示每次提交的方式。git将提交表示为快照，而mercurial将其表示为diff。
在实践中这意味着什么？好吧，许多操作在git中都更快，例如切换到另一个提交，比较提交等。特别是如果这些提交距离很远的话。
AFAIK没有Mercurial的方法的优势。
没有。他们俩都一样，都表现差不多。您应该选择一个而不是另一个的唯一原因是，如果您帮助的项目已经使用了一个。
选择一个的另一个可能原因是仅支持其中一个系统的应用程序或服务。例如，由于github .. 我几乎选择学习git 。
也是google的比较（尽管有点旧，于2008年完成）
如果我正确地理解它们（并且我与每个专家都相距甚远），那么从根本上来说，每个人都有不同的哲学。我第一次使用水银9个月。现在我已经用git了6。
hg是版本控制软件。它的主要目标是跟踪软件的版本。
git是基于时间的文件系统。目的是为文件系统添加另一个维度。大多数都有文件和文件夹，git会增加时间。由于VCS是其设计的副产品，因此它的工作确实很棒。
在hg中，有一个一直试图维护的整个项目的历史记录。默认情况下，我相信hg希望所有用户在推和拉时对所有对象进行所有更改。
在git中只有一个对象池，这些跟踪文件（分支/头）确定那些对象的哪一组代表处于特定状态的文件树。当推入或拉出git时，仅发送要推入或拉出的特定分支所需的对象，这是所有对象的一小部分。
就git而言，没有“ 1项目”。您可以在同一个仓库中全部包含50个项目，而git则不在乎。每个人都可以在同一个仓库中单独管理，并且生活良好。
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两者都有一个叫做“分支”的东西，这对于讨论来说非常令人困惑，但是它们并不是完全相同的。当不同的回购协议之间存在冲突时，就会产生分支。git中的分支显然类似于hg中的克隆。但是，尽管克隆可能会给出类似的行为，但绝对是不同的。考虑我使用相当大的铬仓库在git vs hg中尝试这些。
$ 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分支的等效项，我不知道它是什么。
我在一定程度上了解汞和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这样大的项目中，在分支之间切换也几乎是瞬时的。我实际上不知道如何在汞中做到这一点。它不是我已阅读的任何教程的一部分。
另一大不同。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 add --patch请参阅linux.die.net/man/1/git-add或使用git add -i，例如在stackoverflow.com/questions/2372583/…中
checkout -b <name>可以直接使用它git branch <name>来创建一个新分支，而无需切换到该分支
versioncontrolblog上有一个动态比较表，您可以在其中比较几个不同的版本控制系统。
dir-a/foo.c到dir-b/foo.c并保持工作dir-b/foo.c，那么你的工作dir-a/foo.c将是正确的拉带后，我的工作合并。
与分支机构（尤其是短期分支机构）合作时，存在很大的差异。
在这篇文章（BranchingExplained）中进行了解释，该文章将Mercurial与Git进行了比较。
去年的某个时候，我对git和hg进行了评估以供自己使用，并决定使用hg。我觉得它看起来像是一种更清洁的解决方案，并且在当时的更多平台上效果更好。不过，这主要是折腾。
最近，由于git-svn和充当Subversion客户端的功能，我开始使用git。这为我赢得了胜利，现在我完全切换到了git。我认为它的学习曲线稍高一些（特别是如果您需要深入研究的话），但这确实是一个很棒的系统。我将去阅读John现在发布的这两篇比较文章。
我目前正在从SVN迁移到DVCS的过程中（在写博客时，我的发现是我第一次真正的写博客的努力……），并且我已经做了一些研究（=搜索）。据我所知，您可以使用这两个软件包完成大多数操作。似乎git具有更多或更好地实现的高级功能，我确实感觉到与Windows集成对于使用TortoiseHg的软件来说要好一些。我知道也有Git Cheetah（我都尝试过），但是这种商品解决方案感觉更强大。
看到它们都是开源的（对吗？），我认为它们都不会缺少重要的功能。如果重要的事情，人们会要求它，人们会编写代码。
我认为，对于常规做法，Git和Mercurial绰绰有余。他们两个都有使用它们的大型项目（Git-> linux内核，Mercurial-> Mozilla基础项目，当然还有其他两个项目），因此我不认为它们确实缺少任何东西。
话虽这么说，我对其他人对此的看法很感兴趣，因为它将为我的博客工作提供重要的资源；-)
在InfoQ关于DVCS的指南中，有关于 git，Mercurial和Bazaar的大量比较表和图表。
我意识到这不是答案的一部分，但在那一点上，我还认为针对NetBeans和Eclipse等平台的稳定插件的可用性在其中哪个工具更适合该任务，或者说哪个工具更重要。最适合“你”。也就是说，除非您真的想通过CLI方式进行操作。
Eclipse（以及所有基于它的东西）和NetBeans有时在远程文件系统（例如SSH）和文件的外部更新方面都存在问题。这就是为什么您希望自己选择的任何东西都能“无缝”工作的另一个原因。
我现在也正试图为我自己回答这个问题..我已经将候选人归结为Git或Mercurial ..谢谢大家在不信奉宗教的情况下提供了关于该主题的有用信息。
Mercurial和git的另一个有趣的比较：Mercurial与Git。主要关注内部及其对分支过程的影响。
有人认为VCS系统必须很复杂。他们鼓励在现场发明术语和概念。他们可能会认为，有关该主题的众多博士学位会很有趣。其中可能是设计Git的那些。
Mercurial的设计思路不同。开发人员不必太在乎VCS，而应该将时间花在其主要功能上：软件工程。Mercurial允许用户使用并愉快地滥用系统，而不会让他们犯任何不可恢复的错误。
任何专业工具都必须带有设计清晰且直观的CLI。Mercurial用户可以通过发出简单的命令而没有任何奇怪的选择来完成大部分工作。在Git双破折号中，疯狂的选择是常态。如果您是CLI的人，Mercurial将具有很大的优势（老实说，任何自尊的软件工程师都应该如此）。
举个例子，假设您错误地进行了提交。您忘记编辑一些文件。要撤消您在Mercurial中的操作，只需键入：
$ hg rollback
然后，您会收到一条消息，提示系统撤消您上一次的交易。
在Git中，您必须输入：
$ git reset --soft HEAD^
好吧，假设您知道复位的含义。但是除此之外，您还必须知道什么是“-软”和“-硬”重置（任何直观的猜测？）。哦，当然不要忘了最后的'^'字符！（现在以里奇的名义...）
Mercurial与第三方工具kdiff3和meld的集成也要好得多。生成补丁可以合并分支，而不必大惊小怪。Mercurial还包括一个简单的http服务器，您可以通过键入以下内容来激活它
hg serve
并让其他人浏览您的存储库。
最重要的是，Git以更复杂的方式并且以劣等的CLI来完成Mercurial的工作。如果要将项目的VCS变成科学研究领域，请使用Git。如果您想完成VCS任务而不关心它，请使用Mercurial，并专注于实际任务。