logo标签列表

你为什么选择使用Git而不是Mercurial？（或相反）

gitmercurialdvcs
27

我目前使用Git，并且总体上对它感到满意，但我想了解更多关于Mercurial的信息。它是否比Git更具有优势？Git相对于Mercurial的优势是什么？

我知道已经有两者之间的详细比较，但这不是我所要求的。我不想要客观的信息，而是希望得到充满激情（但要有礼貌！）的理由，让你认为其中一个更好/更容易/更快/更聪明/更强等等。

5
请参阅 https://dev59.com/3HI-5IYBdhLWcg3w8dYQ 了解客观的比较，https://dev59.com/uXVD5IYBdhLWcg3wQZUg 和 https://dev59.com/SXE85IYBdhLWcg3w9ohJ 了解更多“热情”的意见。 - VonC
1
应该设置为社区维基，因为您似乎在寻求主观答案。 - Ben James
1
认为 X 比 Y 更好的 结论 可能被认为是主观的，但 原因 不是主观的，我要求的是 原因。人们对 Git 或 Mercurial 充满热情并不意味着他们基于自己观点的事实不再是事实。事实就是事实。原因就是原因，我要求的是原因。 - iconoclast
11个回答
28

我曾经使用过Mercurial和Git，但我更喜欢hg而不是git；它只是感觉更好。Steve Losh在他的博客文章Mercurial和Git之间的真正区别中总结了我的大部分感受。以下是一些我完全同意的引用：

我认为仍然有一个非常非常重要的区别：系统的使用感觉非常不同。

我个人认为Mercurial的理念更易于使用。当命令更加模块化而不是单一时，我更容易理解。

我个人不喜欢索引。我觉得git鼓励人们提交未经测试（甚至未构建）的代码更改集，因为索引在git工作流程中是如此突出。
我发现索引很难处理 - 如果我想要像那样的东西（而且更强大），我会使用mq。同时 - 为什么我被迫拥有不同类型的添加等？为什么我被迫使用git commit -a（并且具有git status - 其中是git st？ - 显示奇怪的信息）？
相当严肃地说，我个人认为git的成功和广泛接受除了GitHub之外别无选择。Steve也抓住了这一点。有多少人经历过这种情况，并“屈服于”git用户的压力？
我不喜欢使用git本身（尽管它比SVN或CVS好得多），但GitHub是一个非常棒的网站，我考虑切换只是为了使用它。
我只会在必要时继续使用git/GitHub - 当我想对其中某个内容进行修补时。我的项目将继续使用Mercurial。感觉更好。
4
虽然我认为GitHub是一个很强的影响力，但说“没有别的东西”这样的话语还是相当不公平的。（在这方面更重要的是 Linux 内核！）其他回答在这里和其他地方列出了明显的优点（如轻量级分支的易用性）。而您的一些抱怨似乎也有些可疑。索引如何会鼓励缺乏测试呢？如果有人添加并提交未经测试的代码，那么如果没有索引，他们肯定也会提交它。我完全相信 Mercurial 对您和许多其他人来说可能感觉更好、更直观，但没必要挑刺去证明它的价值。 - Cascabel
1
@Jefromi：对于像Linux内核这样的东西，这很好，但我不相信这解释了它的广泛接受度。尽管它比今天还不可用，但它开始变得流行（这就是为什么它比过去更可用的原因），我只能看到GitHub是引起这种情况的原因。关于提交未经测试的代码，请阅读Steve文章的其余部分，我认为这会更有意义。 - Chris Morgan
3
我认为你低估了Linus Torvalds及其朋友支持某事所具有的重要性。无论如何，GitHub直到2008年才推出。当时Git版本为v1.5.4（距离v1.0将近三年时间），已经相当受欢迎且可用。GitHub确实做出了很多贡献，但Git在此之前已经牢固确立。 - Cascabel
3
我记得在2008年1月的第一届acts_as_conference上，Git明显是最受欢迎的选择。Github在那一年的4月份推出。虽然在正式推出之前已经有了beta版本，但它可能仍然对Git产生了某种影响。但像Randal Schwartz关于Git的演讲对我更有影响力。在我的印象中，Github的发展部分来源于Ruby程序员普遍认为Git是未来的技术这一强烈共识。反过来，Github增强了Git的地位。（艺术反映现实还是现实反映艺术？两者皆有。） - iconoclast
别忘了，Mercurial是用Python编写的！ :) - hochl
自从写下这些内容以来，我越来越多地使用Git（我只在私人项目中使用Mercurial，并且在我的公共OSS项目和工作中使用Git），我现在比写这篇文章时更加熟悉它。我可能不会再说我非常喜欢hg而不是git了，但我仍然更喜欢它。我已经接受了索引并发现有时很方便，但与此同时，Mercurial已经发展出其变更集演化功能，仍然做得更好。 - Chris Morgan
15

(A) 我选择使用 Git 而不是 Mercurial 的前三个真实原因:

  1. 历史随机性/惯性
  2. 历史随机性/惯性
  3. 历史随机性/惯性

(B) 基于上述原因，我喜欢 Git 胜过 Mercurial 的三个方面:

  1. 索引 (index)
  2. 轻量级分支 (lightweight branches)
  3. 合理的标签管理 (标签不是跟随被打标签的提交)

(C) Mercurial 相对于 Git 具有以下三个优势:

  1. 更好的本地化文档 (强调 "本地化"，因为 ProGit 书籍 真的很优秀，任何对 Git 或 Git 模型过于复杂或令人困惑的抱怨都应直接参考此书)
  2. 连续的提交编号 (仅在本地库范围内，但当进行琐碎操作时，这可能比复制粘贴 SHA-1 更方便?)
  3. 更漂亮的标志/名称?

我认为 (B) 中列出的所有（大部分？）项目要么是我习惯于 Git 模型的结果，要么可以通过插件在 Mercurial 中“修复”。但事实仍然存在，即 Git 开箱即用，符合我的预期，而我可以不关心任何 (C) 的项目 [考虑到出色的 ProGit 书籍，C(1) 不再是问题]。因此，我继续使用 Git 而不是 Mercurial。

4
我认为Mercurial 的顺序提交编号实际上会对其造成不利影响。我喜欢相同的SHA1哈希意味着在宇宙中的任何仓库中都表示相同的提交。（但重要的是这些哈希可以被缩短）。 - Norman Ramsey
1
现在许多人使用GitHub是另一个真正的原因。 - Paul Draper
4
关于“I love it that the same SHA1 hash means the same commit in any repository in the universe. (But it is crucial that those hashes can be abbreviated.)”：我想指出Mercurial的工作方式完全相同。每个变更集都有自己的SHA1十六进制ID。相关存储库中相同的ID表示相同的变更集。顺序编号特定于本地存储库，并且与使用40个字符长（或缩短的）ID相比，它使在本地工作更加容易。我不明白为什么这会“对Mercurial造成影响”。 - AbVog
Mercurial还具有索引/暂存功能，甚至比Git更强大。这被称为Mercurial MQ。Mercurial还具有轻量级分支功能，称为“书签”。 - Slimer
12

我使用Mercurial的主要原因是:

  1. 它支持我通常使用的更多的开源仓库（即Bitbucket和Codeplex）
  2. 它在Windows上开箱即用，表现良好

否则，就版本控制操作本身而言，它们基本相同。

（编辑说明：为了澄清 - 我并不是说Mercurial优于Git - 据我了解，在一般用法中Git比Mercurial更快速，而且我实际上没有使用过足够多的Git来发表评论。但这两个原因是我使用Mercurial而不是Git的原因）

1
Hg在Windows上不仅可以直接使用，而且表现非常出色。我每天都在Linux和Windows机器上使用hg，实际上我对它在Windows上的性能、功能或可用性没有任何抱怨。 - Lucas
@Lucas：好的，它“在任何版本控制系统可以工作的范围内工作”。更好了吗？ :P - Billy ONeal
9
没有，Mercurial和Git非常相似。个人认为它们之间的差异被高度夸大和热情化，经不起更深入的审视。
有一些小差异。Git比Mercurial更倾向于暴露模型。Mercurial命令集比Git小，并反映了这种哲学。
大部分其他功能都可以通过使用Mercurial强大的扩展模型来实现。它还具有易于扩展的优点，因为大多数Mercurial代码都是用Python编写的，并且您可以像运行本机Mercurial命令一样运行扩展名。
可通过以下讨论获取额外信息和详细信息。
查看以下链接，了解Git和Mercurial之间的差异：

为什么我更喜欢Mercurial而不是Git。

[再次是个人的热情和偏见]

Mercurial的命令真正只是Git可用命令的子集，看起来非常充足。任何额外的东西，感觉都有点过度放纵。

6
我使用Mercurial是因为code.google.com支持它。我也使用它是因为它主要用Python编写，易于扩展。而且在许多操作系统上都很容易安装。一些与我合作的人害怕使用命令行，喜欢使用GUI工具，所以我会向他们推荐TortoiseHg。
两者各有优缺点。使用你更熟悉的那个即可。
额外链接：

gitvsmercurial.com

通过Wayback Machine访问gitvsmercurial.com

事后分析

自从写下这个答案以来，我主要使用git，主要是因为GitHub。我在工作中也开始使用Subversion。但我宁愿不使用Subversion。

5

同样的事情，换汤不换药。我从Mercurial转向Git是因为团队中另外一个人更喜欢它。然而，我认为他之所以更喜欢它只是因为他先学会了它。

5
你可以使用两者实现相同的功能，但这并不意味着差异是肤浅的。
我已经使用Git几年了，最近一个月开始每天都使用Mercurial，我发现它们之间有明显的不同感觉。
到目前为止，我的经验是，在集中式工作流程中进行协作时，Mercurial更难以保持私有开发分支，而不是保留多个存储库的副本。使用Git需要明确分享哪些内容。
因此，使用Git进行非正式的编码会感觉轻松得多；例如，如果它是一个工作项目，可能会做一些“不应该”做的事情。这降低了尝试新想法的心理障碍。
由于我喜欢在自己的存储库副本上做任何我想做的事情，并且只与他人共享我希望他们看到的内容（以及对他们有用的内容），因此我更喜欢Git，因为它似乎更容易做到这一点。
另外一件事：我第一次看到Mercurial的Python API时非常兴奋（因为我是Python用户）。我认为写扩展程序会很有趣。然而，我看到了API不保证兼容的warnings，于是我很快地感到失望并放弃了这个想法。
1
我认为你提到的分支问题非常重要，但往往被忽视。个人而言，我认为轻量级分支是一个至关重要的功能。当然，我听说Mercurial书签可以帮助解决这个问题，现在它们甚至可以在仓库之间传输，所以也许这不再是一个问题了？ - Cascabel
谢谢你的建议，Jefromi。我现在已经尝试了书签；虽然它们显然很轻量级，但我不明白它们如何更容易保持私密性（因为每个被书签的提交也在一个分支上，所以如果你推送该分支，它也会被推送）。 - Ben James
啊，我自己并没有真正使用过Mercurial；我只是在阅读中了解到Mercurial中轻量级“分支”概念下的书签。听起来似乎还存在着实际的不足之处。 - Cascabel
5

我喜欢使用Git，因为：

  • 它对我来说似乎更快。
  • 内置的工具更多。
  • 有更高的帮助、问题和讨论资源（甚至在本网站上）。
  • GitHub非常实用。
  • 目前在Javascript和Ruby社区中，有大量活跃/前沿的Git开发。
10
GitHub相较于BitBucket有哪些优势？虽然BitBucket提供免费的私人代码库，但我认为Mercurial在这方面优势更大。 - Wim Coenen
我没有尝试过BitBucket，但是GitHub在很多方面都非常棒。你必须亲自尝试才能欣赏它。虽然（正如你所指出的那样）BitBucket的定价可能更好，但这不能归结为定价水平问题。（我并不是在争论GitHub更好：只是试图至少部分回答你为什么有人会指向GitHub作为选择Git的原因。） - iconoclast
3
除了Github本身之外，还有所有在Github上的代码。这才是真正重要的，对吧？ - iconoclast
5
当我几年前审查分布式版本控制系统时：
- bzr与Python 2.4绑定，无法直接在2.5上安装/运行。 - 在Windows上，git的支持最多只能算得上是勉强。
这就只剩下hg了。我一直很满意hg。hg社区似乎对用户体验非常关注，这让我这个用户感到高兴。相比之下，git的用户体验似乎需要很长时间才能开始朝着“易用性”方向发展，这不会让我对它产生好感。
我认为hg还需要一些东西：灵活的元数据和大文件处理。然而，这些方面并不会干扰我的常规使用情况，如果我真的需要，我可以写/修改扩展程序而不会遇到太大的困难。
2
虽然在易用性上有一些差异（我对Git的主要不满之处是默认情况下不启用颜色；Hg默认情况下缺乏分页器、颜色、colordiff的hack和清除功能——仅因为有扩展框架并不意味着你不应该将它们发布并在所有地方启用），但我坚持使用Git的一个重要原因是它在我关心的社区中具有更多的关注度。尽管Hg在Mozilla项目方面处于领先地位，但Git已成为Arbales提到的社区（特别是JavaScript和Web基础设施）、Gnome、内核显然以及我发现有用的长尾随机项目的标准。

并不是因为有网络效应就意味着营销决定了一切。Git的工具集是生成性的和非常高效的（它被用于许多备份、归档和数据完整性方面）；Hg的扩展必须是生成性的，但更多地是在UI增强方面。Git开创了一些有用的标准，比如快速导入。我认为这就是它吸引了更多的系统构建者类型，他们既能改进git、完善它，又能将自己的东西放入git。

1
默认禁用颜色不应成为批评一个旨在通过终端运行的应用程序的理由。 - elmt
如果它是tty并且$TERM是合理的，为什么不呢？分页器已经使用了相同的启发式方法。 - Tobu
1
因为历史上，终端应用程序默认不启用颜色。一个有效的例子是“ls”命令，它需要设置“color=auto”选项。 - elmt
4
我认为 Git 使用分页器的论点也类似 - 应该使用 --pager（或者留给 |less），而不是 --no-pager。通常情况下，我并不需要分页器。对于可执行文件来说，使用分页器并不是一种正常的做法。 - Chris Morgan
1
但是请比较一下：hg log会清除屏幕，只留下最旧的修订版本。而git log则会显示最近的修订版本，并允许我进行导航。一个处理常见用例，而另一个则不是。至于传统方面：man命令是否异常？ - Tobu
显示剩余3条评论
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接