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就足夠了。

　　全文完，覺得不錯的話點個贊或者在看吧！