Mercurial 和 Git 有什么区别？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/35837/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What is the Difference Between Mercurial and Git?
提问by Spoike
I've been using git for some time now on Windows (with msysGit) and I like the idea of distributed source control. Just recently I've been looking at Mercurial (hg) and it looks interesting. However, I can't wrap my head around the differences between hg and git.
我已经在 Windows 上使用 git 一段时间了（使用 msysGit），我喜欢分布式源代码控制的想法。就在最近，我一直在研究 Mercurial (hg)，它看起来很有趣。但是，我无法理解 hg 和 git 之间的差异。
Has anyone made a side-by-side comparison between git and hg? I'm interested to know what differs hg and git without having to jump into a fanboy discussion.
有没有人对 git 和 hg 进行并排比较？我很想知道 hg 和 git 有什么不同，而不必跳入狂热的讨论中。
采纳答案by jfs
These articles may help:
这些文章可能会有所帮助：
- Git vs. Mercurial: Please Relax(Git is MacGyver and Mercurial is James Bond)
- The Differences Between Mercurial and Git
- Git vs. Mercurial：请放松（Git 是 MacGyver，Mercurial 是 James Bond）
- Mercurial 和 Git 的区别
Edit: Comparing Git and Mercurial to celebrities seems to be a trend. Here's one more:
编辑：将 Git 和 Mercurial 与名人进行比较似乎是一种趋势。还有一个：
回答by Martin Geisler
I work on Mercurial, but fundamentally I believe both systems are equivalent. They both work with the same abstractions: a series of snapshots (changesets) which make up the history. Each changeset knows where it came from (the parent changeset) and can have many child changesets. The recent hg-gitextension provides a two-way bridge between Mercurial and Git and sort of shows this point.
我在 Mercurial 上工作，但从根本上说，我相信这两个系统是等效的。它们都使用相同的抽象：构成历史的一系列快照（变更集）。每个变更集都知道它来自哪里（父变更集）并且可以有许多子变更集。最近的hg-git扩展提供了 Mercurial 和 Git 之间的双向桥梁，并在某种程度上说明了这一点。
Git has a strong focus on mutating this history graph (with all the consequences that entails) whereas Mercurial does not encourage history rewriting, but it's easy to do anywayand the consequences of doing so are exactly what you should expect them to be (that is, if I modify a changeset you already have, your client will see it as new if you pull from me). So Mercurial has a biastowards non-destructive commands.
Git 非常注重改变这个历史图（以及随之而来的所有后果），而 Mercurial 不鼓励历史重写，但无论如何这样做很容易，这样做的后果正是你应该期望的（即，如果我修改了您已经拥有的变更集，如果您从我这里提取，您的客户会将其视为新的）。所以 Mercurial偏向于非破坏性命令。
As for light-weight branches, then Mercurial has supported repositories with multiple branchessince..., always I think. Git repositories with multiple branches are exactly that: multiple diverged strands of development in a single repository. Git then adds names to these strands and allow you to query these names remotely. The Bookmarksextension for Mercurial adds local names, and with Mercurial 1.6, you can move these bookmarks around when you push/pull..
至于轻量级分支，Mercurial 一直支持具有多个分支的存储库...，我一直认为。具有多个分支的 Git 存储库正是这样：单个存储库中的多个不同的开发链。Git 然后将名称添加到这些链中，并允许您远程查询这些名称。Mercurial的书签扩展添加了本地名称，并且在 Mercurial 1.6 中，您可以在推/拉时移动这些书签。
I use Linux, but apparently TortoiseHg is faster and better than the Git equivalent on Windows (due to better usage of the poor Windows filesystem). Both http://github.comand http://bitbucket.orgprovide online hosting, the service at Bitbucket is great and responsive (I haven't tried github).
我使用 Linux，但显然 TortoiseHg 比 Windows 上的 Git 等价物更快更好（由于更好地使用了较差的 Windows 文件系统）。无论http://github.com和http://bitbucket.org提供在线托管，在到位桶的服务是伟大的，响应的（我没有尝试过的github）。
I chose Mercurial since it feels clean and elegant -- I was put off by the shell/Perl/Ruby scripts I got with Git. Try taking a peek at the git-instaweb.shfileif you want to know what I mean: it is a shellscript which generates a Rubyscript, which I think runs a webserver. The shell script generates another shell script to launch the first Ruby script. There is also a bit of Perl, for good measure.
我选择了 Mercurial，因为它感觉干净和优雅——我被我用 Git 获得的 shell/Perl/Ruby 脚本所推迟。如果您想知道我的意思，请尝试查看该git-instaweb.sh文件：它是一个shell脚本，它生成一个Ruby脚本，我认为它运行一个网络服务器。shell 脚本生成另一个 shell 脚本来启动第一个 Ruby 脚本。还有一点Perl，很好的衡量标准。
I like the blog postthat compares Mercurial and Git with James Bond and MacGyver -- Mercurial is somehow more low-key than Git. It seems to me, that people using Mercurial are not so easily impressed. This is reflected in how each system do what Linus described as "the coolest merge EVER!". In Git you can merge with an unrelated repository by doing:
我喜欢将 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
Those commands look quite arcane to my eye. In Mercurial we do:
这些命令在我看来很神秘。在 Mercurial 中，我们这样做：
hg pull --force <project-to-union-merge>
hg merge
hg commit
Notice how the Mercurial commands are plain and not special at all -- the only unusual thing is the --forceflag to hg pull, which is needed since Mercurial will abort otherwise when you pull from an unrelated repository. It is differences like this that makes Mercurial seem more elegant to me.
请注意 Mercurial 命令是多么简单而且一点都不特别——唯一不寻常的是--force标志 to hg pull，这是必需的，因为当您从不相关的存储库中提取时，Mercurial 将中止。正是这样的差异让 Mercurial 在我看来更加优雅。
回答by Aristotle Pagaltzis
Git is a platform, Mercurial is “just” an application. Git is a versioned filesystem platform that happens to ship with a DVCS app in the box, but as normal for platform apps, it is more complex and has rougher edges than focused apps do. But this also means git's VCS is immensely flexible, and there is a huge depth of non-source-control things you can do with git.
Git 是一个平台，Mercurial“只是”一个应用程序。Git 是一个版本化的文件系统平台，它碰巧附带了一个 DVCS 应用程序，但与平台应用程序一样，它比专注的应用程序更复杂，也更粗糙。但这也意味着 git 的 VCS 非常灵活，并且您可以使用 git 进行大量非源代码控制的事情。
That is the essence of the difference.
这就是差异的本质。
Git is best understood from the ground up – from the repository format up. Scott Chacon's Git Talkis an excellent primer for this. If you try to use git without knowing what's happening under the hood, you'll end up confused at some point (unless you stick to only very basic functionality). This may sound stupid when all you want is a DVCS for your daily programming routine, but the genius of git is that the repository format is actually very simple and you canunderstand git's entire operation quite easily.
Git 最好从头开始理解——从存储库格式开始。Scott Chacon 的 Git Talk是一个很好的入门读物。如果您在不知道幕后发生了什么的情况下尝试使用 git，您最终会在某个时候感到困惑（除非您只坚持非常基本的功能）。当您想要的只是日常编程例程的 DVCS 时，这可能听起来很愚蠢，但 git 的天才在于存储库格式实际上非常简单，您可以很容易地理解 git 的整个操作。
For some more technicality-oriented comparisons, the best articles I have personally seen are Dustin Sallings':
对于一些更技术性的比较，我个人看过的最好的文章是 Dustin Sallings 的：
- The Differences Between Mercurial and Git
- Reddit thread where git-experienced Dustin answers his own git neophyte questions
He has actually used both DVCSs extensively and understands them both well – and ended up preferring git.
他实际上广泛使用了这两种 DVCS 并且对它们都了如指掌——最终更喜欢 git。
回答by mmiika
The big difference is on Windows. Mercurial is supported natively, Git isn't. You can get very similar hosting to github.comwith bitbucket.org(actually even better as you get a free private repository). I was using msysGit for a while but moved to Mercurial and been very happy with it.
最大的区别是在 Windows 上。Mercurial 是本机支持的，Git 不是。您可以使用bitbucket.org获得与github.com非常相似的托管（实际上，当您获得免费的私人存储库时会更好）。我使用 msysGit 有一段时间了，但后来转向 Mercurial 并且对它非常满意。
回答by Maurice Flanagan
If you are a Windows developer looking for basic disconnected revision control, go with Hg. I found Git to be incomprehensible while Hg was simple and well integrated with the Windows shell. I downloaded Hg and followed this tutorial (hginit.com)- ten minutes later I had a local repo and was back to work on my project.
如果您是 Windows 开发人员，正在寻找基本的断开版本控制，请使用 Hg。我发现 Git 难以理解，而 Hg 很简单并且与 Windows shell 很好地集成在一起。我下载了 Hg 并遵循了本教程 (hginit.com)- 十分钟后我有了一个本地存储库，并重新开始我的项目。
回答by Cyberdrow
I think the best description about "Mercurial vs. Git" is:
我认为关于“Mercurial vs. Git”的最佳描述是：
回答by Arialdo Martini
They are almost identical. The most important difference, from my point of view (I mean, the reason that got me to choose one DVCS over the other) is how the two programs manage branches.
它们几乎相同。从我的角度来看，最重要的区别（我的意思是，让我选择一个 DVCS 而不是另一个的原因）是这两个程序如何管理分支。
To start a new branch, with Mercurial, you simply clone the repository to another directoryand start developing. Then, you pull and merge. With git, you have to explicitly give a name to the new topic branch you want to use, then you start coding using the same directory.
要使用 Mercurial 启动一个新分支，您只需将存储库克隆到另一个目录并开始开发。然后，你拉和合并。使用 git，您必须明确地为要使用的新主题分支命名，然后使用相同的目录开始编码。
In short, each branch in Mercurial needs its own directory; in git you usually work in on single directory. Switching branches in Mercurial means changing directories; in git, it means asking git to change the directory's content with git checkout.
简而言之，Mercurial 中的每个分支都需要自己的目录；在 git 中，您通常在单个目录中工作。在 Mercurial 中切换分支意味着更改目录；在 git 中，这意味着要求 git 使用 git checkout 更改目录的内容。
I'm honest: I don't know if it's possible to do the same with Mercurial, but since I usually work on web projects, using always the same directory with git seems much confortable to me, since I don't have to re-configure Apache and restart it and I don't mess my filesystem everytime I branch.
老实说：我不知道是否可以用 Mercurial 做同样的事情，但是因为我通常在 web 项目上工作，所以总是使用与 git 相同的目录对我来说似乎很舒服，因为我不必重新- 配置 Apache 并重新启动它，每次我分支时都不会弄乱我的文件系统。
Edit: As Deestan noted, Hg has named branches, which can be stored in a single repository and allow the developer to switch branches within the same working copy. git branches are not exactly the same as Mercurial named branches, anyway: they are permanent and not throw away branches, like in git. That means that if you use a named branch for experimental tasks even if you decide to never merge it it will be stored in the repository. That's the reason why Hg encourages to use clones for experimental, short-running tasks and named branches for long-running tasks, like for release branches.
编辑：正如 Deestan 所指出的，Hg 已命名分支，它可以存储在单个存储库中，并允许开发人员在同一工作副本中切换分支。无论如何，git 分支与 Mercurial 命名分支并不完全相同：它们是永久性的，不会像 git 那样丢弃分支。这意味着，如果您将命名分支用于实验任务，即使您决定从不合并它，它也会存储在存储库中。这就是为什么 Hg 鼓励将克隆用于实验性的、短期运行的任务并为长期运行的任务使用命名分支，例如发布分支。
The reason why a lot of Hg users prefere clones over named branch is much more social or cultural than technical. For example, with last versions of Hg, it's even possible to close a named branch and recursively remove metadata from changesets.
许多 Hg 用户更喜欢克隆而不是命名分支的原因更多是社会或文化而不是技术。例如，使用最新版本的 Hg，甚至可以关闭命名分支并从变更集中递归删除元数据。
On the other side, git invites to use "named branches" which are not permanent and are not stored as metadata on each changeset.
另一方面，git 邀请使用“命名分支”，这些分支不是永久性的，也不会作为元数据存储在每个变更集上。
From my personal point of view, then, git's model is deeply linked to the concept of named branches and switch between a branch and another withing the same directory; hg can do the same with named branches, but yet it encourages the use of clones, which I personally don't like too much.
那么，从我个人的角度来看，git 的模型与命名分支和在同一目录下的分支之间切换的概念密切相关；hg 可以对命名分支做同样的事情，但它鼓励使用克隆，我个人不太喜欢它。
回答by FelipeC
There's one hugedifference between gitand mercurial; the way the represent each commit. gitrepresents commits as snapshots, while mercurialrepresents them as diffs.
git和mercurial之间有一个巨大的区别；代表每次提交的方式。git将提交表示为快照，而mercurial将它们表示为差异。
What does this means in practice? Well, many operations are faster in git, such as switching to another commit, comparing commits, etc. Specially if these commits are far away.
这在实践中意味着什么？好吧，在 git 中许多操作都更快，例如切换到另一个提交，比较提交等。特别是如果这些提交距离很远。
AFAIK there's no advantage of mercurial's approach.
AFAIK mercurial 的方法没有优势。
回答by KalEl
Also google's comparison (though it's a bit old, done in 2008)
还有google的比较（虽然有点旧，2008年做的）
回答by dbr
Nothing. They both do the same, both perform about equally. The only reason you should choose one over the other is if you help out with a project that already uses one..
没有。他们都做同样的事情，两者的表现差不多。你应该选择一个而不是另一个的唯一原因是如果你帮助一个已经使用了一个的项目..
The other possible reason for choosing one is an application or service which only supports one of the system.. For example, I pretty much chose to learn git because of github..
选择一个的另一个可能的原因是一个应用程序或服务只支持一个系统。例如，我几乎选择学习 git 因为github..
