互聯(lián)網(wǎng)巨頭決定拋棄Git......

2005年4月，Larry發(fā)現(xiàn)有Linux內(nèi)核開發(fā)者違反了協(xié)議，正在對自己的寶貝軟件BitKeeper做逆向工程，他怒不可遏，撤銷了Linux的使用許可。

（詳情參見：被Linux之父力挺的軟件，開源后倒下了...）

Linux一下子面臨著沒有源碼管理系統(tǒng)的窘境！

這件事情影響很大，第一，Linus Torvalds不得不停下內(nèi)核的開發(fā)和管理工作，開始開發(fā)Git。

第二，它促使Olivia Mackall發(fā)布了幾周前開發(fā)的Mercurial v0.1 ，和Git一樣，這也是一個(gè)可擴(kuò)展的分布式版本控制系統(tǒng)。

兩個(gè)分布式版本控制系統(tǒng)可以說是同時(shí)起步。

很明顯，頂著Linux光環(huán)的Git（當(dāng)然它自身非常優(yōu)秀）受到了更多人的歡迎，很多公司選擇了Git，其中就包括互聯(lián)網(wǎng)巨頭Facebook。

隨著業(yè)務(wù)的飛速發(fā)展，F(xiàn)acebook的代碼庫也開始以驚人的速度增長。

單單是2013年，F(xiàn)acebook的Git代碼倉庫就提交了4.4萬個(gè)文件，1700萬行代碼，甚至比Linux內(nèi)核的規(guī)模更龐大，更復(fù)雜。

更要命的是，Facebook和另外一個(gè)巨頭Google一樣，把公司的所有項(xiàng)目代碼都“塞”到了一個(gè)代碼庫中！

為什么要單一代碼庫的策略呢？這么做有很多好處：

(1) 統(tǒng)一的版本化管理，不需要fork 共享庫，沒有跨代碼庫merge復(fù)制代碼的痛苦

(2) 廣泛的代碼共享和復(fù)用

(3) 簡化的依賴管理

(4) 跨團(tuán)隊(duì)的合作很方便

可是，隨著單一代碼庫的飛速增長，Git操作變得越來越慢。

Facebook的工程師對未來幾年的代碼庫規(guī)模做了估計(jì)，創(chuàng)建了一個(gè)虛擬倉庫做一個(gè)模擬，結(jié)果讓人震驚，基本的Git命令都需要45分鐘才能完成！

必須得尋找解決方案了！

Facebook組建了一個(gè)團(tuán)隊(duì)，專門來解決這個(gè)問題。

他們先是聯(lián)系了Git維護(hù)者，但是要想解決Facebook的問題，Git內(nèi)部必須得做一些深度的代碼修改不可。

所以Git維護(hù)者的回復(fù)是：你們的代碼庫太大了，應(yīng)該分拆代碼庫......

Git社區(qū)對于提升單一超大代碼庫的性能并不是十分積極，因?yàn)楹苌偃诉@么用啊！

Git這條路走不通，F(xiàn)acebook又考慮了閉源的Perforce，這也是一個(gè)老牌的版本控制系統(tǒng)，成立于1995年。

Salesforce、Netflix、SAP、迪士尼、Intuit和紐約證券交易所都是它的客戶，Google也曾經(jīng)用過，Perforce在游戲領(lǐng)域是領(lǐng)導(dǎo)者，游戲廠商前20強(qiáng)有18家在用Perforce做版本控制。

在和Perforce的銷售工程師接觸的時(shí)候，F(xiàn)acebook發(fā)現(xiàn)Perforce在“讀取和寫入節(jié)點(diǎn)的本地一致性存在缺陷。” 不過Perforce并不認(rèn)為這是一個(gè)大問題，也沒有計(jì)劃來解決它。

放棄了Perforce以后，一個(gè)有豐富Mercurial使用經(jīng)驗(yàn)的工程師建議考慮一下Mercurial。

Mercurial用Python寫成，采用了面向?qū)ο蟮母鞣N模式，架構(gòu)更簡潔，更容易擴(kuò)展。

比如對于Facebook這樣大規(guī)模的存儲(chǔ)庫，一個(gè)主要的瓶頸就是找出哪些文件發(fā)生了變化。Git的辦法是檢查每個(gè)文件，隨著文件數(shù)量的增加，就會(huì)變得越來越慢。

Facebook內(nèi)部有個(gè)工具叫做watchman，可以檢測文件的狀態(tài)變化，Mercurial 良好設(shè)計(jì)使得和watchman的集成非常簡單，最終集成了watchman的Mercurial在查看文件狀態(tài)時(shí)，比Git快了5倍以上。

Mercurial還有幾個(gè)很好的抽象，例如filelog，這個(gè)數(shù)據(jù)結(jié)構(gòu)表示每個(gè)文件的每次修訂，F(xiàn)acebook通過remotefilelog擴(kuò)展了這個(gè)接口，使得超大存儲(chǔ)庫的pull和clone速度提升了10倍以上，從幾分鐘縮短到幾秒鐘。

Mercurial社區(qū)也非常開放，愿意和Facebook合作，為了解決Facebook遇到的問題，可以對Mercurial做出重大變革。

雙方合作相當(dāng)良好，F(xiàn)acebook從Git向Mercurial遷移的時(shí)候，在一年半的時(shí)間內(nèi)貢獻(xiàn)了500多個(gè)補(bǔ)丁，包括新的圖算法，用C語言重寫性能關(guān)鍵的部分等等。

Mercurial則認(rèn)真地審閱這些補(bǔ)丁，主動(dòng)幫助Facebook解決擴(kuò)展性問題，在設(shè)計(jì)新功能的時(shí)候也會(huì)把Facebook的問題考慮在內(nèi)。

這和當(dāng)時(shí)的Git社區(qū)形成了鮮明的對比。

十年后，Git也做出了重大改進(jìn)，可以很好地處理非常大的單一存儲(chǔ)庫，但

Facebook不會(huì)再遷移回來了。

說完了Facebook，再來說說Google。

Google的代碼庫更大，更加嚇人。

截止到2015年，這個(gè)代碼庫一共有20億行代碼，占據(jù)了86T的空間。 

數(shù)字沒有直觀感覺，看個(gè)圖吧：Windows，Office等常見軟件在中間，Google代碼庫是最下方的綠色方塊。

除了Chrome和Android之外，大部分Google產(chǎn)品的代碼都保存在一個(gè)代碼庫中。

Google最早用的版本控制系統(tǒng)是閉源的Perforce，可見在創(chuàng)業(yè)初期，像版本管理這樣的工具，大家都是拿來就用的，不考慮什么開源不開源的。

為了支撐自己業(yè)務(wù)的發(fā)展，Google不斷地想辦法擴(kuò)展Perforce，但是擴(kuò)展也是到了盡頭：CPU超負(fù)荷運(yùn)轉(zhuǎn)，時(shí)不時(shí)出現(xiàn)TCP連接失敗。

Google也考慮了Git，但當(dāng)時(shí)Git的主流觀點(diǎn)是：應(yīng)該使用更多更小的代碼庫。這和Google單一代碼庫的理念是完全相反。

就像2005年Linus被迫發(fā)明Git一樣，Google也被迫發(fā)明了自己新的版本管理系統(tǒng)：Piper

新工具開發(fā)起來很容易，但是把數(shù)據(jù)從Perforce遷移到Piper非常難。

在過去的11年間，Perforce已經(jīng)深深地融入了Google的生態(tài)系統(tǒng)，基于Perforce Google已經(jīng)開發(fā)了300多種工具。

2010年，Oracle狀告Google，指控它在Android中使用了未經(jīng)授權(quán)的Java API，這給Google敲響了警鐘，千萬不用復(fù)制Perforce的API。

最后Google工程師不得不采用了“潔凈室”的技術(shù)，由獨(dú)立的，對Perforce API一無所知的工程師來進(jìn)行設(shè)計(jì)。

向Piper的遷移花費(fèi)了4年的時(shí)候，才大功告成。

Facebook和Google都是標(biāo)準(zhǔn)的互聯(lián)網(wǎng)巨頭，在他們代碼庫的發(fā)展過程中，一直堅(jiān)持單一代碼庫的策略，都“拋棄”了Git。

Facebook選擇現(xiàn)成開源軟件Mercurial，瘋狂魔改，使其滿足自己的要求。

Google則選擇發(fā)明一個(gè)新輪子Piper，花費(fèi)巨大經(jīng)歷進(jìn)行遷移。

他們所做的事情，不是一般公司能干的，對絕大多數(shù)公司來說，選擇Git就足夠了。

全文完，覺得不錯(cuò)的話點(diǎn)個(gè)贊或者在看吧！

      

       

        


        
點(diǎn)擊關(guān)注公眾號，閱讀更多精彩內(nèi)容