我在 Windows（使用 msysGit）上使用 git 已经有一段时间了，我喜欢分布式源代码控制的想法。就在最近，我一直在看 Mercurial (hg)，它看起来很有趣。但是，我无法理解 hg 和 git 之间的差异。
有没有人在 git 和 hg 之间进行并排比较？我很想知道 hg 和 git 有什么不同，而不必参加狂热的讨论。
【问题讨论】：
标签： git version-control mercurial comparison dvcs
这些文章可能会有所帮助：
编辑：将 Git 和 Mercurial 与名人进行比较似乎是一种趋势。还有一个：
【讨论】：
我在 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 在我看来更加优雅。
【讨论】：
git pull <url-of-project>。您引用的邮件来自 git 的早期（2005 年）
Git 是一个平台，Mercurial “只是”一个应用程序。 Git 是一个版本化的文件系统平台，它恰好附带一个 DVCS 应用程序，但与平台应用程序一样，它比专注的应用程序更复杂且边缘更粗糙。但这也意味着 git 的 VCS 非常灵活，您可以使用 git 做大量非源代码控制的事情。
这就是区别的本质。
最好从头开始理解 Git——从存储库格式开始。 Scott Chacon’s Git Talk 是一个很好的入门。如果你在不知道底层发生了什么的情况下尝试使用 git，你最终会感到困惑（除非你只坚持非常基本的功能）。当您想要的只是日常编程例程的 DVCS 时，这听起来可能很愚蠢，但 git 的天才之处在于存储库格式实际上非常简单，您可以很容易地理解 git 的整个操作。 p>
对于一些更注重技术性的比较，我个人看过的最好的文章是 Dustin Sallings 的：
他实际上已经广泛使用了这两种 DVCS，并且对它们都非常了解——最终他更喜欢 git。
【讨论】：
最大的区别在于 Windows。 Mercurial 是本机支持的，Git 不支持。您可以使用bitbucket.org 获得与github.com 非常相似的托管（实际上，当您获得免费的私人存储库时更好）。我使用 msysGit 有一段时间了，但后来改用 Mercurial 并且对它非常满意。
【讨论】：
如果您是寻找基本断开连接的修订控制的 Windows 开发人员，请选择 Hg。我发现 Git 难以理解，而 Hg 很简单并且与 Windows shell 很好地集成在一起。我下载了 Hg 并关注了 this tutorial (hginit.com) - 十分钟后，我有了一个本地 repo 并重新开始我的项目。
【讨论】：
我认为关于“Mercurial vs. Git”的最佳描述是：
【讨论】：
它们几乎相同。 从我的角度来看，最重要的区别（我的意思是，让我选择一个 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 可以对命名分支做同样的事情，但它鼓励使用克隆，我个人不太喜欢。
【讨论】：
git 和 mercurial 之间有一个巨大的区别；代表每个提交的方式。 git 将提交表示为快照，而 mercurial 将它们表示为差异。
这在实践中意味着什么？好吧，在 git 中很多操作更快，例如切换到另一个提交、比较提交等。特别是如果这些提交距离很远。
据我所知，mercurial 的方法没有任何优势。
【讨论】：
什么都没有。他们都做同样的事情，都表现得差不多。你应该选择一个而不是另一个的唯一原因是如果你帮助一个已经使用一个的项目..
另一个可能的原因是应用程序或服务只支持其中一个系统。例如，我几乎选择学习 git 是因为github..
【讨论】：
还有google的对比（虽然有点老，2008年做的）
【讨论】：
如果我对它们的理解正确（而且我远不是这方面的专家），它们基本上都有不同的哲学。我第一次使用 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 add --patch，见linux.die.net/man/1/git-add或使用git add -i，如stackoverflow.com/questions/2372583/…
git branch <name> 来创建一个新分支，而不是用checkout -b <name> 签出master 和分支
版本控制博客上有一个动态比较图表，您可以在其中比较几个不同的版本控制系统。
【讨论】：
dir-a/foo.c 重命名为dir-b/foo.c 并继续处理dir-b/foo.c，那么您在dir-a/foo.c 上的工作将在拉取后正确地与我的工作合并。
在与分支机构合作（尤其是短期分支机构）方面存在很大差异。
在将 Mercurial 与 Git 进行比较的 this article (BranchingExplained) 中有解释。
【讨论】：
您的项目中是否有任何基于 Windows 的合作者？
因为如果有的话，Git-for-Windows GUI 看起来很笨拙、困难、不友好。
相比之下，Mercurial-on-Windows 就很简单了。
【讨论】：
在 bitbucket.org 的 mercurial 和 github 的 git 之间需要注意的一点是，mercurial 可以拥有任意数量的私有存储库，但是 github 你必须升级到付费帐户。所以，这就是我选择使用 mercurial 的 bitbucket 的原因。
【讨论】：
去年的某个时候，我为自己的使用评估了 git 和 hg，并决定使用 hg。我觉得它看起来像一个更清洁的解决方案，并且当时在更多平台上运行得更好。不过，这主要是一次折腾。
最近，由于 git-svn 和充当 Subversion 客户端的能力，我开始使用 git。这赢得了我的支持，我现在已经完全切换到 git。我认为它的学习曲线略高（特别是如果你需要探索内部），但它确实是一个很棒的系统。我要去阅读约翰现在发布的那两篇比较文章。
【讨论】：
我目前正处于从 SVN 迁移到 DVCS 的过程中（同时在博客上讲述我的发现，我的第一次真正的博客工作......），并且我做了一些研究（=谷歌搜索）。据我所知，你可以用这两个包做大部分事情。看起来 git 有更多或更好的实现高级功能， 我确实觉得与 windows 的集成对于 mercurial 和 TortoiseHg 来说更好一些。我知道还有 Git Cheetah（我两种都试过了），但是这种反复无常的解决方案感觉更健壮。
看看它们都是开源的（对吗？）我认为它们都不会缺少重要的功能。如果某件事很重要，人们会要求它，人们会对其进行编码。
我认为对于常见的做法，Git 和 Mercurial 绰绰有余。他们都有使用它们的大项目（Git -> linux 内核，Mercurial -> Mozilla 基金会项目，当然还有其他），所以我认为两者都没有真正缺乏什么。
话虽如此，我对其他人对此的看法很感兴趣，因为它会成为我写博客的重要来源；-)
【讨论】：
InfoQ's guide about DVCS 上提供了关于 git、Mercurial 和 Bazaar 的出色而详尽的比较表和图表。
【讨论】：
我意识到这不是答案的一部分，但在这一点上，我还认为 NetBeans 和 Eclipse 等平台的稳定插件的可用性在该工具更适合该任务方面发挥了作用，或者更确切地说，哪个工具最适合“你”。也就是说，除非您真的想要通过 CLI 方式进行操作。
Eclipse（以及基于它的所有东西）和 NetBeans 有时都会在远程文件系统（例如 SSH）和文件的外部更新方面出现问题；这也是为什么您希望您选择“无缝”工作的另一个原因。
我现在也在尝试为自己回答这个问题 .. 我已经将候选者归结为 Git 或 Mercurial .. 感谢大家在不信教的情况下就该主题提供有用的意见。
【讨论】：
mercurial 和 git 的另一个有趣的比较：Mercurial vs Git。 主要关注内部结构及其对分支过程的影响。
【讨论】：
如果您对 Mercurial 和 Git 的性能比较感兴趣，请查看 this article。结论是：
Git 和 Mercurial 都取得了不错的成绩，但在速度和存储库大小之间做出了有趣的权衡。 Mercurial 的添加和修改速度都很快，同时可以控制存储库的增长。 Git 也很快，但在您重新打包之前，它的存储库会随着修改过的文件快速增长——而这些重新打包可能会非常慢。但是打包后的存储库比 Mercurial 的要小得多。
【讨论】：
mercurial 网站在两个系统之间有一个great description of the similarities and differences，解释了词汇和底层概念的差异。作为一个长期使用 git 的用户，它确实帮助我理解了 Mercurial 的心态。
【讨论】：
如果您从 SVN 迁移，请使用 Mercurial，因为它的语法对于 SVN 用户来说更容易理解。除此之外，你也不会出错。但请在选择其中一个之前检查GIT tutorial 和HGinit。
【讨论】：
【讨论】：
有些人认为 VCS 系统必须很复杂。他们鼓励在该领域发明术语和概念。他们可能会认为许多关于这个主题的博士会很有趣。其中可能是设计 Git 的人。
Mercurial 的设计理念不同。开发人员不应该太关心 VCS，而应该把时间花在他们的主要功能上：软件工程。 Mercurial 允许用户使用并愉快地滥用系统，而不会让他们犯任何不可恢复的错误。
任何专业工具都必须带有设计清晰且直观的 CLI。 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。
【讨论】：