我已经在Windows(使用msysGit)上使用git一段时间了，我喜欢分布式源代码管理的想法。就在最近，我一直在研究Mercurial(hg)，它看起来很有趣。但是，我无法解决hg和git之间的差异。

有没有人在git和hg之间进行并排比较？我有兴趣知道hg和git的不同之处，而不必参加狂热的讨论。

解决方案

回答

我目前正在从SVN迁移到DVCS的过程中(在写博客时，我的发现是我第一次真正的写博客的努力……)，并且我已经做了一些研究(=查阅)。据我所知，我们可以使用这两个软件包完成大多数操作。似乎git具有更多或者更好实施的高级功能，
我确实感觉到，与TortoiseHg相比，与Windows的集成要好一些。我知道也有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-svn和充当Subversion客户端的能力，我开始使用git。这为我赢得了胜利，现在我完全切换到了git。我认为它的学习曲线略高(特别是如果我们需要深入研究)，但这确实是一个很棒的系统。我将去阅读John现在发布的这两篇比较文章。

回答

没有。他们俩都一样，都表现差不多。我们应该选择一个而不是另一个的唯一原因是，如果我们帮助的项目已经使用了一个。

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

回答

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

回答

最大的区别是在Windows上。 Mercurial本身受支持，而Git则不受支持。我们可以使用bitbucket.org获得与github.com非常相似的托管服务(实际上，获得免费的私有存储库甚至更好)。我使用msysGit已有一段时间，但后来搬到Mercurial并对此感到非常满意。

回答

Git是一个平台，Mercurial只是一个应用程序。 Git是一个版本化的文件系统平台，刚好随附了DVCS应用程序，但与平台应用程序一样，它比集中应用程序更复杂且边缘更粗糙。但这也意味着gits VCS非常灵活，并且我们可以使用git进行大量的非源代码控制。

这就是差异的本质。

最好从存储库格式的底层开始就对Git有所了解。 Scott Chacons Git Talk是对此的出色入门。如果我们尝试使用git而不了解幕后发生的事情，那么我们最终会在某个时候感到困惑(除非我们仅坚持非常基本的功能)。当我们想要的只是日常编程例程的DVCS时，这听起来可能很愚蠢，但是git的天才之处在于，存储库格式实际上非常简单，我们可以很容易地理解gits的整个操作。

对于一些更注重技术性的比较，我个人看到的最好的文章是Dustin Sallings：

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

他实际上已经广泛使用了这两种DVCS，并且对它们都了解得很深，因此最终选择了git。

回答

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

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

回答

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

回答

我认为关于" Mercurial vs. Git"的最好描述是：

"吉特是韦斯利·斯奈普斯。水星是丹泽尔·华盛顿"

回答

我从事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文件：这是一个生成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命令是简单明了的，而根本不是特殊的-唯一不寻常的是对hg pull的--force标志，这是必需的，因为从不相关的存储库中提取时Mercurial将会中止。正是这种差异使Mercurial在我看来更加优雅。

回答

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

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

AFAIK没有Mercurial的方法的优势。

回答

与分支机构(尤其是短期分支机构)合作时，存在很大的差异。

在这篇文章(BranchingExplained)中进行了解释，该文章将Mercurial与Git进行了比较。

回答

也是google的比较(尽管有点旧，于2008年完成)

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

回答

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

Git and Mercurial both turn in good numbers but make an interesting trade-off between speed and repository size. Mercurial is fast with both adds and modifications, and keeps repository growth under control at the same time. Git is also fast, but its repository grows very quickly with modified files until you repack — and those repacks can be very slow. But the packed repository is much smaller than Mercurial's.

回答

它们几乎是相同的。
从我的角度来看(最重要的区别是，我选择一个DVCS而不是另一个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)，我有一个本地存储库，然后又可以在我的项目上工作了。