Git，Mercurial和Bazaar的相对优势和劣势是什么？

Question

这里的人们认为Git，Mercurial和Bazaar的相对优势和劣势是什么？

在考虑彼此之间以及SVN和Perforce等版本控制系统时，应该考虑哪些问题？

在计划从SVN迁移到其中一个分布式版本控制系统时，您会考虑哪些因素？

Answer 1

Git速度非常快，非常好，并且对其概念非常透明。不利的一面是它有一个相对陡峭的学习曲线。可以使用Win32端口，但不是一流的公民。 Git将哈希值作为版本号暴露给用户;这提供了保证（因为单个散列总是指完全相同的内容;攻击者无法在未被检测到的情况下修改历史记录），但对用户来说可能很麻烦。 Git具有跟踪文件内容的独特概念，即使这些内容在文件之间移动，并将文件视为第一级对象，但不跟踪目录。 git的另一个问题是有许多操作（例如 rebase ），这使得修改历史记录变得容易（从某种意义上说 - 哈希引用的内容永远不会改变，但是对该哈希的引用可能会丢失）;一些纯粹主义者（包括我自己）不太喜欢这样。

Bazaar速度相当快（对于历史较浅的树木速度非常快，但目前的历史长度很差），并且易于学习熟悉传统SCM命令行界面的人员（CVS，SVN等） ）。 Win32被其开发团队视为一流的目标。它具有适用于不同组件的可插拔架构，并经常替换其存储格式;这允许他们引入新功能（例如更好地支持与基于不同概念的版本控制系统集成）并提高性能。 Bazaar团队考虑目录跟踪并重命名支持一流的功能。虽然全局唯一版本ID标识符可用于所有修订，但使用树本地revnos（标准版本号，更类似于svn或其他更常规SCM使用的版本）来代替用于标识修订的内容哈希。 Bazaar支持“轻量级检出”，其中历史记录保存在远程服务器上，而不是复制到本地系统，并在需要时通过网络自动引用;目前，这在DSCM中是独一无二的。

两者都有某种形式的SVN集成;但是，bzr-svn比git-svn更强大，主要是由于为此目的引入的后端格式修订。 [更新，截至2014年：第三方商业产品SubGit提供SVN和Git之间的双向接口，其保真度与bzr-svn相当，并且更加精致;当预算和许可限制允许时，强烈建议将其用于git-svn。

我没有广泛使用Mercurial，因此无法对其进行详细评论 - 除非注意它与Git一样，具有内容哈希寻址用于修订;也像Git一样，它不会将目录视为第一类对象（并且不能存储空目录）。然而，除了Git之外，它比任何其他DSCM都快，并且具有比任何竞争对手更好的IDE集成（特别是对于Eclipse）。鉴于其性能特征（仅略落后于Git）及其卓越的跨平台和IDE支持，Mercurial可能对拥有大量以win32为中心或IDE成员的团队具有吸引力。

从SVN迁移的一个问题是SVN的GUI前端和IDE集成比任何分布式SCM更成熟。此外，如果您当前大量使用SVN预先提交脚本自动化（即在提交可以继续之前要求单元测试通过），您可能希望使用类似于PQM的工具来自动执行合并请求你的共享分支。

SVK是一个DSCM，它使用Subversion作为其后备存储，并且与SVN中心工具具有很好的集成。但是，它的性能和可伸缩性特性比任何其他主要的DSCM（甚至是Darcs）都要差得多，对于那些在历史长度或文件数量方面都有可能增长的项目应该避免使用。

[关于作者：我使用Git和Perforce工作，Bazaar用于我的个人项目和嵌入式库;我雇主组织的其他部分大量使用Mercurial。在以前的生活中，我围绕SVN建立了大量的自动化;在此之前我有GNU Arch，BitKeeper，CVS等经验。 Git起初相当令人反感 - 感觉就像GNU Arch一样，因为它是一个概念沉重的环境，而不是为了符合用户选择的工作流程而构建的工具包 - 但我已经非常熟悉了它]。

Answer 2

史蒂夫Streeting的Ogre 3D项目（2009年9月28日）发表了一篇关于这个主题的博客文章，他做了一个很棒的，甚至是comparison of Git, Mercurial and Bazaar。

最后他发现这三者都有优点和缺点，没有明显的赢家。从好的方面来说，他提供了一个很好的表格来帮助你决定选择哪一个。

简短阅读，我强烈推荐它。

Answer 3

---

这里的人们认为Git，Mercurial和Bazaar的相对优势和劣势是什么？

在我看来， Git 的优势在于其干净的底层设计和非常丰富的功能。我认为它也是对多分支存储库和管理分支繁重工作流的最佳支持。它非常快，并且存储库大小很小。

它有一些有用的功能，但需要付出一些努力才能使用它们。这些包括工作区和存储库数据库之间的可见中间登台ara（索引），这允许在更复杂的情况下更好地合并解决，增量编译和与脏树进行对比; 检测使用相似性启发式重命名和复制，而不是使用某种文件ID跟踪它们，这种方式很好，并且允许责备（注释），它可以跟踪文件之间的代码移动，而不仅仅是批量重命名。

其缺点之一是MS Windows支持滞后而且未满。另一个明显的缺点是，它没有像Mercurial那样有据可查，并且比竞争对手的用户友好性差，但它会发生变化。

在我看来， Mercurial 的优势在于其良好的性能和较小的存储库大小，以及良好的MS Windows支持。

主要的不满是我认为本地分支（单个存储库中的多个分支）仍然是二等公民的事实，并且以奇怪和复杂的方式实现标记。它处理文件重命名的方式也不是最理想的（但是这个迁移已经改变了）。 Mercurial不支持章鱼合并（有两个以上的父母）。

从我所听到的内容和阅读主要 Bazaar 的优点是它可以轻松支持集中式工作流程（这也是不利的，集中式概念在不应该的地方可见），跟踪两个文件的重命名和目录。

它的主要缺点是具有长非线性历史的大型存储库的性能和存储库大小（至少对于不太大的存储库，性能得到改善），默认范例是每个存储库的一个牧场（您可以将其设置为共享数据） ，虽然）和集中的概念（但也从我听到的变化）。

Git是用C，shell脚本和Perl编写的，并且是可编写脚本的; Mercurial是用C（核心，性能）和Python编写的，并提供扩展API; Bazaar是用Python编写的，并提供扩展API。

---

在考虑彼此之间以及SVN和Perforce等版本控制系统时，应该考虑哪些问题？

Subversion（SVN），Perforce或ClearCase等版本控制系统是集中式版本控制系统。 Git，Mercurial，Bazaar（以及Darcs，Monotone和BitKeeper）是分布式版本控制系统。分布式版本控制系统允许更广泛的工作流程。他们允许使用“准备好时发布”。他们更好地支持分支和合并，以及分支繁重的工作流程。您不需要信任具有提交权限的人，以便能够以简单的方式从他们那里获得贡献。

---

在计划从SVN迁移到其中一个分布式版本控制系统时，您会考虑哪些因素？

您可能需要考虑的因素之一是支持与SVN的合作; Git有git-svn，Bazaar有bzr-svn，而Mercurial有hgsubversion扩展。

免责声明：我是Git用户和小时间撰稿人，并观看（并参与）git邮件列表。我只知道Mercurial和Bazaar的文档，IRC和邮件列表的各种讨论，以及比较各种版本控制系统的博客文章和文章（其中一些列在Git Wiki的GitComparison页面上）。

Answer 4

InfoQ有a nice comparison。

Answer 5

Mercurial和Bazaar在表面上非常相似。它们都提供基本的分布式版本控制，如在离线提交和合并多个分支时，都是用python编写的，并且都比git慢。一旦你深入研究代码，就会有很多不同之处，但是，对于日常的日常任务，它们实际上是相同的，尽管Mercurial似乎有更多的动力。

Git，嗯，不适合没有经验的人。它比Mercurial和Bazaar快得多，并且是为了管理Linux内核而编写的。这是三者中最快的，也是三者中最强大的，相当大的余地。 Git的日志和提交操作工具是无与伦比的。然而，它也是使用最复杂和最危险的。丢失提交或破坏存储库非常容易，特别是如果你不理解git的内部工作原理。

Answer 6

看看Python开发人员最近做的比较：http://wiki.python.org/moin/DvcsComparison。他们基于三个重要原因选择了Mercurial：

  

与Mercurial合作的选择有三个重要原因：

     

  
• 根据一项小型调查，Python开发人员对使用Mercurial更感兴趣   比在Bazaar或Git。
  
• Mercurial是用Python编写的，它与python-dev倾向于“吃自己的狗食”一致。
  
• Mercurial明显快于bzr（它比git慢，但差异要小得多）。
  
• 对于SVN用户而言，Mercurial比Bazaar更容易学习。
  

     

（来自http://www.python.org/dev/peps/pep-0374/）

Answer 7

Sun对git，Mercurial和Bazaar进行了评估，以替换Solaris代码库中的Sun Teamware VCS。我发现它非常有趣。

Answer 8

市集中一个非常重要的缺失的事情是cp。您不能拥有与SVN中相同历史记录的多个文件，例如请参阅here和here。如果你不打算使用cp，bzr是一个很好的（也很容易使用）替代svn。

Answer 9

我正在使用Bazaar一段时间，我很喜欢，但它只是较小的项目，即便如此，它也很慢。这么容易学习，但不是超级快。它虽然是非常x平台。

我目前使用Git，因为版本1.6使得它在使用命令方面与其他VCS更相似所以我非常喜欢。

我认为使用DVCS的经验主要区别在于：

1. Git拥有最活跃的社区，看到有关Git
的文章很常见
2. GitHub真的很震撼。 Launchpad.net没问题，但没有像Github的快乐
3. Git的工作流程工具数量很多。它集成了整个地方。 Bzr有一些，但没有那么多或维护得很好。

总结一下，当我在DVCS上磨牙时，Bzr非常棒，但我现在对Git和Github非常满意。

Answer 10

这是一个很大的问题，很大程度上依赖于上下文，这会花费你很多时间来输入这些小文本框之一。此外，当大多数程序员使用通常的东西时，所有这三个看起来都非常相似，所以即使理解差异也需要一些相当深奥的知识。

如果你可以将这些工具的分析打破到更具体的问题，你可能会得到更好的答案。

Answer 11

Bazaar比git更容易学习恕我直言。 Git在github.com上有很好的支持。

我认为你应该尝试使用两者并决定哪个最适合你。

Answer 12

  

这里的人们认为Git，Mercurial和Bazaar的相对优势和劣势是什么？

这是一个非常开放的问题，接近火焰棒。

Git是最快的，但这三个都足够快。 Bazaar是最灵活的（它具有对SVN存储库的透明读写支持），并且非常关注用户体验。 Mercurial位于中间位置。

这三个系统都有很多粉丝。我个人是Bazaar的粉丝。

  

在考虑彼此之间以及SVN和Perforce等版本控制系统时，应该考虑哪些问题？

前者是分布式系统。后者是集中式系统。此外，Perforce是专有的，而其他所有其他都是免费的as in speech。

集中与分散是比你在其类别中提到的任何系统更为重要的选择。

  

在计划从SVN迁移到其中一个分布式版本控制系统时，您会考虑哪些因素？

首先，缺少TortoiseSVN的良好替代品。尽管Bazaar正在开发他们自己的Tortoise variant，但截至2008年9月它还没有。

然后，培训关键人物如何使用分散式系统将影响他们的工作。

最后，与系统的其他部分集成，例如问题跟踪器，夜间构建系统，自动化测试系统等。

Answer 13

ddaa.myopenid.com顺便提到了它，但我认为值得一提：Bazaar可以读取和写入远程SVN存储库。这意味着您可以在本地使用Bazaar作为概念验证，而团队的其他成员仍在使用Subversion。

编辑：几乎所有工具现在都有与SVN交互的一些方式，但我现在有个人经验，git svn很好地工作非常。我已经使用它好几个月了，只有极少的打嗝。

Answer 14

您的主要问题是这些分布式 SCM，因此需要对用户的思维方式进行一些更改。一旦人们习惯了这个想法，技术细节和使用模式就会落实到位，但不要低估最初的障碍，特别是在公司环境中。请记住，所有问题都是人的问题。

Answer 15

Linus Torvalds在git上有很好的视频。他是Git的创造者，所以这就是他所宣传的内容，但在视频中他解释了SCM的分布以及为什么它们比集中式SCM更好。有很多比较git（mercurial被认为是OK）和cvs / svn / perforce。观众也有关于迁移到分布式SCM的问题。

我发现这件材料很有启发性，我被卖给分发的SCM。但尽管莱纳斯的努力，我的选择是多变的。原因是bitbucket.org，我发现它比github更好（更慷慨）。

我需要在这里说一句警告：Linus有着相当激进的风格，我觉得他很有趣但是我没有笑。除此之外，如果您不熟悉分布式SCM并考虑从SVN移动，那么该视频非常棒。

http://www.youtube.com/watch?v=4XpnKHJAok8

Answer 16

分布式版本控制系统（DVCS）解决了与集中式VCS不同的问题。比较它们就像比较锤子和螺丝刀一样。

Centralized VCS系统的设计意图是有一个真正的来源，有福，因此是好的。所有开发人员从该源开始工作（checkout），然后添加（提交）他们的更改，然后变为类似的Blessed。 CVS，Subversion，ClearCase，Perforce，VisualSourceSafe和所有其他CVCS之间唯一真正的区别在于每个产品提供的工作流程，性能和集成。

设计

Distributed VCS系统的目的是使一个存储库与其他存储库一样好，并且从一个存储库到另一个存储库的合并只是另一种形式的通信。关于应该信任哪个存储库的任何语义值都是通过进程从外部强加的，而不是由软件本身强加的。

使用一种类型或另一种类型之间的真正选择是组织 - 如果您的项目或组织想要集中控制，那么DVCS是非启动者。如果您的开发人员希望在全国/世界各地工作，没有安全的宽带连接到中央存储库，那么DVCS可能是您的救星。如果你需要两者，你就是fsck'd。