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

‍

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

（详情参见：被 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) 跨团队的合作很方便

可是，随着单一代码库的飞速增长，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 不会再迁移回来了。

说完了 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年的时候，才大功告成。

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

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

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

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

作者介绍

本文作者刘欣，著有畅销书《码农翻身》，《半小时漫画计算机》，前 IBM 架构师，领导过多个企业应用架构设计和开发工作；洞察技术本质，擅长用故事去讲解复杂技术。

转载自丨码农翻身

作者 | 刘欣

编辑丨王梦玉   

相关阅读 | Related Reading

关于召开《开放原子硬件许可协议》（征求意见稿）研讨会的通知

AI 革命不会被垄断：开源力量挑战巨头主导

开源社简介

开源社（英文名称为“KAIYUANSHE”）成立于 2014 年，是由志愿贡献于开源事业的个人志愿者，依 “贡献、共识、共治” 原则所组成的开源社区。开源社始终维持 “厂商中立、公益、非营利” 的理念，以 “立足中国、贡献全球，推动开源成为新时代的生活方式” 为愿景，以 “开源治理、国际接轨、社区发展、项目孵化” 为使命，旨在共创健康可持续发展的开源生态体系。

开源社积极与支持开源的社区、高校、企业以及政府相关单位紧密合作，同时也是全球开源协议认证组织 - OSI 在中国的首个成员。

自2016年起连续举办中国开源年会（COSCon），持续发布《中国开源年度报告》，联合发起了“中国开源先锋榜”、“中国开源码力榜”等，在海内外产生了广泛的影响力。