Git / Mercurial / Bazaar的受欢迎程度与推荐

通过这个网站上的这三个分布式版本控制系统的问题数量,似乎也是Git

  1. 更受欢迎,或者
  2. 比较困难(因此需要更多的问题),或者
  3. 有更多的function(因此需要更多的问题)。

或者最有可能的是三者的结合。 (比方说,这个网站的受欢迎程度相当于普遍受欢迎程度。)这里是数字:

                 |  2009年6月| 七月2010 | 七月2011 | 七月2012 | 七月2013 | 七月2014 | 七月2015 | 七月2016 |  2017年6月
     -------------------------------------------------- -------------------------------------------------- -----------
     [svn] |  2353 |  5323 |  9028 |  12687 |  15587 |  18846 |  21209 |  23037 |  24692
     [git] |  726 |  3725 |  9225 |  17523 |  27862 |  41478 |  55315 |  71056 |  86958
     |  169 |  1120 |  2765 |  4221 |  5230 |  6030 |  6651 |  7134 |  7524
     [bazaar] |  50 |  159 |  252 |  351 |  425 |  483 |  506 |  525 |  534

拥有三个竞争性的但基本相同的开源产品可供select,这并不是完全令人满意的。 就我个人而言,我使用Git,其他两个人都很好。 但是当谈到推荐一个系统的时候,我想问一下:我们可以开始安全地推荐一个系统吗?

从2009年中期开始的评论 :Subversion最近的历史stream行清楚地反映了问题的数量,表明至less在Git上的水银或Bazaar小规模的小规模小费。

从2010年中期的评论 :看看水银数量的巨大的相对增加。 显然,只有两个数据点不足以显示趋势,但看起来Git和Subversion基本上是根深蒂固的,Mercurial看到了很多增长,而Bazaar一直保持相对平静。

简短的评论,2011年年中 :我们可以把Git叫做赢家吗? :)不,我接受这样一个观点,即问题的数量不等于stream行。 数字肯定是强大的,虽然。

2011年11月更新:

与2009年相比,Git现在更加成熟:

  • 智能http现在被支持,这意味着你可以提供给你的客户端https协议来提取/克隆和推送 ,authentication能够与LDAP接口(对于企业用户来说很重要)
  • Gitolite现在已经存在一个成熟的授权层,这意味着您可以为“机密”存储库提供隔离(对于大型公司来说同样重要)。
  • 2009年已经出现的Windows支持依然强劲, TortoiseGit相当稳定
  • 像Eclipse这样的IDE集成正在进行中(大部分Eclipse项目现在都在GitHub上)

然而,在一个集中的环境中安装Git并不是微不足道的:
请参阅“ 分布式版本控制系统和企业 – 一个好的组合? ”


有一点总是错过的是:

他们的性质是不同的。

  • SVN是一个REVISION系统 (它通过廉价的拷贝存储分支和标签!合并支持效率不是很高),它是集中的。
  • Mercurial或bazaar是FILE VCS (它们存储文件的版本)并分发。
    Arne Babenhauserheide用“文件,清单和变更集”指出了历史模型 ,对Mercurial进行了修改。
  • Git,这是非常难以掌握的,是一个CONTENT VCS (它存储内容的三angular洲,而不是文件本身:两个相同内容的文件将只存储一次)

这意味着:

  • 如果你有一个简单的合并工作stream程 ,在一个开发地点,坚持使用SVN
  • 如果你有几个发展的地方,分布式VCS更适应。
  • 如果你有一个复杂的合并工作stream程 ,任何现代的VCS都比SVN更好,这使得合并信息在合适的地方保持多年。 然后,这取决于工具(Mercurial具有更高级的Windows支持)
  • 如果你主要是文本文件而不是太大的二进制文件,Git是非常好的,只要你知道它的限制

通过这个网站上的这三个分布式版本控制系统的问题数量,似乎也是Git

  1. 更受欢迎,或者
  2. 比较困难(因此需要更多的问题),或者
  3. 有更多的function(因此需要更多的问题)。
  1. 关于SCM stream行度 – 请参阅以下StackOverflow问题: Free RCS / SCM / VCS系统是否有任何stream行度/使用情况统计信息? 。 在这里,我们有一些问题,比如什么样的忽略文件用于特定种类的项目,哪些是SCM不可知论的,但是被要求使用Git(和使用'git'标签),因为它是什么人问问题使用。

  2. 关于Git 更困难 (因此对于这个问题有更多的疑问) – 当然,Git的学习曲线更陡。 它也使用了很less(相当)独特的概念,如分区(索引)或所有分支是平等的,这是负责其权力,但可能很难得到一开始(特别是如果一个来自其他单片机) 。 Git UI也不完全一致(虽然它变得更好),因为它是增长而不是开发的; 这是它的权力负责,但可能导致不理想的用户界面。

  3. 关于Git有更多的function – 你将不得不检查有多lessSO问题是关于Git的高级/不常见的function。 不过,你应该知道,开源项目相互借鉴了一些想法,或者有独立开发的类似特性:一个例子是通过平分(search)提交历史来发现错误,这个错误是据我所知首先在Git中,然后在Bazaar中实现插件,并在Mercurial中实现第一个扩展和当前的核心function。 另一个是交互select变化的碎片,由Darcs的行为启发。 还有一个是Git的捆绑理念,借鉴了Mercurial的类似概念。

  4. 还有另外一个更大数量的SO问题的可能性可能是缺乏良好的文档 …虽然现在GIT用户手册 (与Git分发)和Git社区手册 (在Git主页上find)变得更好了。 尽pipe如此,Git还是有比使用Subversion版本控制 (也称为svnbook )和Mercurial:The Definitive Guide (也称为hg-book )的Subversion更糟糕的文档…而且人们不会阅读有时候在StackOverflow上提出问题之前的文档。

拥有三个竞争性的但基本相同的开源产品可供select,这并不是完全令人满意的。 就我个人而言,我使用Git,其他两个人都很好。 但是当谈到推荐一个系统的时候,我想问一下:我们可以开始安全地推荐一个系统吗?

那么,Git和Mercurial几乎在同一时间开始独立开发,作为对Linux内核开发者使用的BitKeeper的免费许可的终止。 Subversion不可能成为集中供应链pipe理的问题,因为在合并跟踪方面缺乏核心支持; 这使得它完全不适合Linux内核的大部分分布式开发模式。 市场可能太慢(至less当时),有点集中(我猜)。

Git更强大(在我看来),Mercurial更简单(在人们看来)和更便携(Python); Git是可脚本化的,基于允许独立重新实现的数据模型(参见例如JGit,用Java编写的git),而Mercurial具有用于编写扩展的Python绑定,并且主要基于允许更改底层存储库格式的API(revlog – revlog-ng )…但这只是我的假设。 他们填补略有不同的利基。

除了没有select被认为是好事? 我们有KDE,我们有GNOME和XFCE(以及其他的窗口pipe理器和桌面环境)。 我们有Emacs和Vim(和其他程序员的编辑); 我们有基于rpm的(如Fedora Core,Mandriva,SuSE)和基于deb的(Debian,Ubuntu)和基于tgz的(Slackware)和基于源代码的(Gentoo)发行版; 我们有KWord,AbiWord和OpenOffice.org …我们有Git,Mercurial和Bazaar。

我使用和推荐mercurial

  • 而不是颠覆,因为它支持分布式开发。 我可以在多台机器上工作并在本地提交。 你不能这样做颠覆,至less不像没有像其他存储库一样摆脱
  • 而不是集市,因为集市的窗户支持是…好的。
  • 而不是git,因为它是a)更简单的学习和使用b)windows支持要好得多

根据我的经验来看,从问题的数量来看,明显地将比较结果与Git和Mercurial进行比较。 原因是双重的:

  1. 看看hg update --helpgit checkout -hgit --help checkout 。 在Mercurial中,我很less发现一些问题,这些问题在hg help中几乎没有回答。

  2. http://mercurial-scm.org/wiki – 如果你需要帮助,你可能会发现它,包括许多Tipps和技巧: http : //mercurial-scm.org/wiki/TipsAndTricks

[注意:随着Subversion 1.7的发布,我的答案中的第一段已经过时了,因为Subversion现在只是在基础文件夹中创build一个“.svn”文件夹,类似于其他的文件夹。

三种颠覆之一的一个优点是,它不会在项目的每个文件夹中创build一个“.svn”文件夹。 通常在基础文件夹中只有一个(“.hg”,“.bzr”或“.git”)。 即使你使用的是集中式存储库模型,单靠svn也可以成为一个很好的理由。 (另外:事实上,我经常使用svk作为我的svn客户端,当使用一个svn仓库只是为了这个function(只有linux,svk在windows上不行))。

当然,颠覆的一个好处是,如果你只需要其中一个子文件夹,你不必检出整个项目。

Canonical(Ubuntu)跟踪其发行版的软件包使用情况 ,因此不需要依靠Stack Exchange问​​题计数来衡量stream行度。 但是,正如其他人所指出的那样,这只跟踪Ubuntu用户和Canonical(Ubuntu)的使用并推荐bzr(sample bias)。 不过…

  2011 2011 2011 Package Aug 3 Sep 29 Dec 9 Change ------ ------ ------ ------ ------ git-core 3647 3402 3236 -11% bzr 4975 5286 6070 +22% mercurial 3411 3387 3461 +1% 

git-core软件包的票数下降让我觉得我做了一些错误,比如从Ubuntu的stream行度表中错误的包名。 或者,即使这个“投票”数与安装有关,而不是实际使用该软件。

这里有一些趋势的历史数据。 在这张表中,我使用了来自Ubuntu的<install>统计数据,但是它显示了从2011年开始的Bazaar和Mercurial的增长速度。尽pipe如此, bzr在2011年落后于git ,但是最近的统计数据显示,在安装的实例中(在Ubuntu上)传递了git

  June Aug Dec Growth Oct Growth 2010 2011 2011 2013 ---- ----- ---- ---- ------ ---- ------ git 94k 159k 171k 80% 165k -3.5% bzr 52k 121k 135k 160% 170k 26.0% hg 36k 68k 75k 110% 95k 26.7% 

免责声明:我在Ubuntu上使用bzr,直到2012年,我使用专门使用git团队。 Bzr与所有其他VCS一起使用,可让您使用一致,直观的bzr命令行语法。 我改用git是为了社交而不是技术上的原因。

由于Git在GitHub上的社会编码起源,Git似乎吸引了大量的追随者。

那么git有这么多用户的原因是Linux内核使用它,所以如果你想做Linux开发,你使用git。

既然有这么多人参与git,我build议使用git,只是由于更大的用户群。 事实上,你上面显示的数字是这个明确的标志。

至于难度,所有的版本控制都是困难的,尤其是分布式的。 乍一看,SVN和CVS并不是很容易(至less对我来说)。 这只是适应版本控制系统的必要学习曲线的一部分。

编辑:既然你添加了一个颠覆参考,我想我会解决它。 我想大多数人会使用svn,因为它有各种各样漂亮的GUI界面。 一般来说,人们不喜欢使用命令行,包括一些开发人员。 git通常在Windows上不能很好地工作(或者至less不是无缝的)。 由于许多人在Windows上,这会杀死潜在用户的数量。

另外,我认为SVN的概念更容易理解,因为svn使用中央存储库而不是分布式系统。 “这是一大堆代码,请在这里添加你的代码”,而不是“这里是一些代码,我的可能与他的不同,他的不同,但是如果你愿意,你可以添加一些东西。

在我看来,svn有更好的文档系统build立。 git的文档是针对更高级别的知识(程序的,而不是程序员的智力),因此在你使用系统之后是有意义的,但是当第一次启动的时候,它看起来就像是一堆gobbeldy-gook。

总的来说,我认为svn一直是更普遍的,因为它的一般操作理念更容易理解,工具易于使用,并且在Windows上有很好的支持。

让我以我的最后两分钟结束,并说我更喜欢git,因为我认为它比我用过的其他任何系统都强大得多。 一旦你开始更好地理解程序,攀爬学习曲线肯定会有好处。

检查以下链接对这个问题的民意调查:

http://www.debian-administration.org/polls/160

来自Eric Sink的一篇有趣的博客文章 。

我通常不会发布,但..

我试过git,bzr和其他几个我忘记了,发现bzr有一个非常非常薄弱的​​地方。 对于大文件,它坚持把整个文件加载到内存中。 这造成了大型二进制文件的问题。

Git在这方面好多了。 至于难度。 我在git bash的窗口中使用git。 在不到一个星期的时间里工作得很好(包括实际的工作和对其他VCS的实验)