Mercurial 和 Git 有什么区别？

我目前正在从 SVN 迁移到 DVCS（同时在博客上讲述我的发现，我的第一个真正的博客努力......），并且我做了一些研究（=谷歌搜索）。据我所知，您可以使用这两个软件包完成大部分操作。似乎 git 具有更多或更好的高级功能， 我确实觉得与 Windows 的集成对于 mercurial 和 TortoiseHg 来说要好一些。我知道还有 Git Cheetah（我都试过了），但多变的解决方案感觉更强大。

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

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

话虽如此，我对其他人对此的看法很感兴趣，因为它将成为我博客努力的重要来源;-）

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

• Git vs. Mercurial：请放松（Git 是 MacGyver，Mercurial 是 James Bond）
• Mercurial 和 Git 之间的区别

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

• Git 是 Wesley Snipes，Mercurial 是 Denzel Washington

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

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

无。它们都做同样的事情，两者的表现大致相同。您应该选择其中一个而不是另一个的唯一原因是，如果您帮助一个已经使用一个的项目。

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

在 InfoQ 的 DVCS 指南中，有关于 git、Mercurial 和 Bazaar 的详尽的比较表和图表。

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

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

这就是区别的本质。

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

对于一些更注重技术性的比较，我个人看到的最好的文章是达斯汀·萨林斯（Dustin Sallings）的：

• Mercurial 和 Git 之间的区别
• Reddit 线程，其中有 git 经验的 Dustin 回答了他自己的 git 新手问题

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

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

这是 git、hg 和 bzr 之间的比较表。

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

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

“Git 是 Wesley Snipes。Mercurial 是丹泽尔·华盛顿”

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

Git 非常注重改变这个历史图（以及随之而来的所有后果），而 Mercurial 不鼓励重写历史，但无论如何这很容易做到，这样做的后果正是你应该期望的（也就是说，如果我修改你已经拥有的变更集，如果你从我那里提取，你的客户会认为它是新的）。因此，Mercurial 偏向于非破坏性命令。

至于轻量级分支，那么 Mercurial 一直支持具有多个分支的存储库......，我一直认为。具有多个分支的 Git 存储库就是这样：在单个存储库中包含多个不同的开发链。然后，Git 会向这些链添加名称，并允许您远程查询这些名称。Mercurial 的书签扩展添加了本地名称，在 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 命令是简单的，一点也不特别——唯一不寻常的是 的标志 ，这是必需的，因为当您从不相关的存储库中提取时，Mercurial 将中止。正是这样的差异使Mercurial在我看来更加优雅。--forcehg pull

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

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

AFAIK Mercurial 的方法没有任何优势。

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

本文 （BranchingExplained） 对此进行了解释，将 Mercurial 与 Git 进行了比较。

还有谷歌的比较（虽然有点老了，是在 2008 年完成的）

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

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

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

它们几乎完全相同。 从我的角度来看，最重要的区别（我的意思是，让我选择一个 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 可以对命名分支做同样的事情，但它鼓励使用克隆，我个人不太喜欢克隆。

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

Eclipse（以及基于它的所有内容）和 NetBeans 有时都存在远程文件系统（如 SSH）和文件的外部更新问题;这也是为什么你希望你选择的任何东西都能“无缝”工作的另一个原因。

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

如果您是 Windows 开发人员，正在寻找基本的断开连接的版本控制，请使用 Hg。我发现 Git 难以理解，而 Hg 很简单，并且与 Windows shell 集成得很好。我下载了 Hg 并按照本教程 （hginit.com） 进行操作 - 十分钟后，我有一个本地存储库并重新开始我的项目。

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

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

相比之下，Mercurial-on-Windows 是不费吹灰之力的。

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

Mercurial网站对两个系统之间的异同进行了很好的描述，解释了词汇和基本概念的差异。作为一个长期的 git 用户，它确实帮助我理解了 Mercurial 的思维方式。

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

如果我正确地理解了它们（而且我远非每个方面的专家），那么从根本上说，它们每个人都有不同的哲学。我第一次使用 mercurial 已经 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 都有所谓的“分支”，但它们并不是完全相同的东西。当不同的存储库之间存在冲突时，就会出现 mercurial 中的分支。git 中的分支显然类似于 hg 中的克隆。但是克隆，虽然它可能会提供类似的行为，但绝对不一样。考虑我使用相当大的 chromium 存储库在 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 相同。这两者都构成了一个全新的工作目录，几乎就像您输入了 .这与在 git 中创建一个新分支不同。它的重量要重得多。如果 hg 中有真正等价的 git 分支，我不知道它是什么。cp -r project project-clone

我知道在某种程度上 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

那么这个阶段的意义何在呢？您可以轻松地分离提交。想象一下，您编辑了游戏手柄 .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 甚至有命令来决定要将同一文件中的哪些特定行复制到阶段，以便您也可以单独拆分这些提交。你为什么要这样做？因为作为单独的提交，其他人只能提取他们想要的提交，或者如果有问题，他们可以只恢复有问题的提交。

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

有些人认为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 以一种更复杂的方式和 CLI 来做 Mercurial 所做的事情。如果你想把你项目的VCS变成一个科学研究领域，请使用Git。如果您想在不关心 VCS 的情况下完成 VCS 工作，并专注于您的实际任务，请使用 Mercurial。