互联网巨头决定抛弃Git......

　　 1

　　 两个软件同时诞生

　　2005年4月，Larry发现有Linux内核开发者违反了协议，正在对自己的宝贝软件BitKeeper做逆向工程，他怒不可遏，撤销了Linux的使用许可。

　　（详情参见：）

　　Linux一下子面临者没有源码管理系统的窘境！

　　这件事情影响很大，第一，Linus Torvalds不得不停下内核的开发和管理工作，开始开发Git。

　　第二，它促使Olivia Mackall发布了几周前开发的Mercurial v0.1 ，和Git一样，这也是一个可扩展的分布式版本控制系统。

　　两个分布式版本控制系统可以说是同时起步。

　　很明显，顶着Linux光环的Git（当然它自身非常优秀）受到了更多人的欢迎，很多公司选择了Git，其中就包括互联网巨头Facebook。

　　随着业务的飞速发展，Facebook的代码库也开始以惊人的速度增长。

　　单单是2013年，Facebook的Git代码仓库就提交了4.4万个文件，1700万行代码，甚至比Linux内核的规模更庞大，更复杂。

　　更要命的是，Facebook和另外一个巨头Google一样，把公司的所有项目代码都“塞”到了一个代码库中！

　　为什么要单一代码库的策略呢？这么做有很多好处：

　　(1) 统一的版本化管理，不需要fork 共享库，没有跨代码库merge复制代码的痛苦

　　(2) 广泛的代码共享和复用

　　(3) 简化的依赖管理

　　(4) 跨团队的合作很方便

　　 2

　　 Faceboo决定抛弃Git

　　可是，随着单一代码库的飞速增长，Git操作变得越来越慢。

　　Facebook的工程师对未来几年的代码库规模做了估计，创建了一个虚拟仓库做一个模拟，结果让人震惊，基本的Git命令都需要45分钟才能完成！

　　必须得寻找解决方案了！

　　Facebook组建了一个团队，专门来解决这个问题。

　　他们先是联系了Git维护者，但是要想解决Facebook的问题，Git内部必须得做一些深度的代码修改不可。

　　所以Git维护者的回复是：你们的代码库太大了，应该分拆代码库......

　　Git社区对于提升单一超大代码库的性能并不是十分积极，因为很少人这么用啊！

　　Git这条路走不通，Facebook又考虑了闭源的Perforce，这也是一个老牌的版本控制系统，成立于1995年。

　　Salesforce、Netflix、SAP、迪士尼、Intuit和纽约证券交易所都是它的客户，Google也曾经用过，Perforce在游戏领域是领导者，游戏厂商前20强有18家在用Perforce做版本控制。

　　在和Perforce的销售工程师接触的时候，Facebook发现Perforce在“读取和写入节点的本地一致性存在缺陷。” 不过Perforce并不认为这是一个大问题，也没有计划来解决它。

　　放弃了Perforce以后，一个有丰富Mercurial使用经验的工程师建议考虑一下Mercurial。

　　Mercurial用Python写成，采用了面向对象的各种模式，架构更简洁，更容易扩展。

　　比如对于Facebook这样大规模的存储库，一个主要的瓶颈就是找出哪些文件发生了变化。Git的办法是检查每个文件，随着文件数量的增加，就会变得越来越慢。

　　Facebook内部有个工具叫做watchman，可以检测文件的状态变化，Mercurial 良好设计使得和watchman的集成非常简单，最终集成了watchman的Mercurial在查看文件状态时，比Git快了5倍以上。

　　Mercurial还有几个很好的抽象，例如filelog，这个数据结构表示每个文件的每次修订，Facebook通过remotefilelog扩展了这个接口，使得超大存储库的pull和clone速度提升了10倍以上，从几分钟缩短到几秒钟。

　　Mercurial社区也非常开放，愿意和Facebook合作，为了解决Facebook遇到的问题，可以对Mercurial做出重大变革。

　　双方合作相当良好，Facebook从Git向Mercurial迁移的时候，在一年半的时间内贡献了500多个补丁，包括新的图算法，用C语言重写性能关键的部分等等。

　　Mercurial则认真地审阅这些补丁，主动帮助Facebook解决扩展性问题，在设计新功能的时候也会把Facebook的问题考虑在内。

　　这和当时的Git社区形成了鲜明的对比。

　　十年后，Git也做出了重大改进，可以很好地处理非常大的单一存储库，但

　　Facebook不会再迁移回来了。

　　 3

　　 Google 发明新轮子

　　说完了Facebook，再来说说Google。

　　Google的代码库更大，更加吓人。

　　截止到2015年，这个代码库一共有20亿行代码，占据了86T的空间。

　　数字没有直观感觉，看个图吧：Windows，Office等常见软件在中间，Google代码库是最下方的绿色方块。

　　除了Chrome和Android之外，大部分Google产品的代码都保存在一个代码库中。

　　Google最早用的版本控制系统是闭源的Perforce，可见在创业初期，像版本管理这样的工具，大家都是拿来就用的，不考虑什么开源不开源的。

　　为了支撑自己业务的发展，Google不断地想办法扩展Perforce，但是扩展也是到了尽头：CPU超负荷运转，时不时出现TCP连接失败。

　　Google也考虑了Git，但当时Git的主流观点是：应该使用更多更小的代码库。这和Google单一代码库的理念是完全相反。

　　就像2005年Linus被迫发明Git一样，Google也被迫发明了自己新的版本管理系统：Piper

　　新工具开发起来很容易，但是把数据从Perforce迁移到Piper非常难。

　　在过去的11年间，Perforce已经深深地融入了Google的生态系统，基于Perforce Google已经开发了300多种工具。

　　2010年，Oracle状告Google，指控它在Android中使用了未经授权的Java API，这给Google敲响了警钟，千万不用复制Perforce的API。

　　最后Google工程师不得不采用了“洁净室”的技术，由独立的，对Perforce API一无所知的工程师来进行设计。

　　向Piper的迁移花费了4年的时候，才大功告成。

　　 4

　　 总结

　　Facebook和Google都是标准的互联网巨头，在他们代码库的发展过程中，一直坚持单一代码库的策略，都“抛弃”了Git。

　　Facebook选择现成开源软件Mercurial，疯狂魔改，使其满足自己的要求。

　　Google则选择发明一个新轮子Piper，花费巨大经历进行迁移。

　　他们所做的事情，不是一般公司能干的，对绝大多数公司来说，选择Git就足够了。

　　全文完，觉得不错的话点个赞或者在看吧！