《ACM通信》有一篇論文《為什么 Google 要把幾十億行代碼放在一個庫？》，作者是谷歌基礎設施小組的工程師。作者詳細講述了Google的代碼為什么全部放在一個庫里面。

一、概述

谷歌最早使用 CVS 進行代碼管理，1999年改為 Perforce。那時是一臺 Perforce 主機，加上各種緩存機。

當時，全公司的代碼就在一個倉庫里面，后來一直沿用這種做法。由于規模不斷增長，Perforce 已經無法滿足需求，谷歌就開始使用自己開發的版本管理系統 Piper。

Piper 架設在谷歌自己的分布式數據庫系統（以前叫 Bigtable，現在改名 Spanner）之上，分布在全世界10個數據中心，保證世界各地的谷歌員工都有良好的訪問速度。

目前，這個代碼倉庫包含10億個文件、3500萬次提交記錄，大小為86TB，用戶達到幾萬人。工作日每秒有50萬次請求，高峰時80萬次，大部分來自自動構建和測試系統。

谷歌90%以上的代碼，放在 Piper 里面。對于那些開源的、需要外部協作的項目，代碼放在 Git，主要是 Android 項目和 Chrome 項目。Git 的特點是，所有歷史記錄都會復制到用戶的本地機器，所以不適合大型項目，必須拆分成更小的庫。以 Android 為例，該項目一共包含800多個獨立的倉庫。

二、Piper 的設計

2.1 結構

整個倉庫采用樹狀結構。每個團隊有自己的目錄。目錄路徑就是代碼的命名空間。每個目錄都有負責人（owner），他負責批準該目錄的文件變動。

2.2 權限控制

Piper 支持文件級別的權限控制。99% 的代碼對所有用戶可見，只有少部分重要的配置文件和機密的關鍵業務，設有訪問限制。

如果機密信息不小心放上了 Piper，文件可以被快速清除。并且，所有的讀寫都有日志，管理員能夠查到誰讀過這個文件。

2.3 工作流

Piper 的工作流（workflow）如下圖。

開發者先創建文件的本地拷貝，這叫做”工作區”（workspace）。完成開發后，工作區的快照共享給其他開發者進行代碼評審。只有通過了評審，代碼才能合并到中央倉庫。

2.4 客戶端

大多數開發者通過一個叫做 CitC 的客戶端，訪問 Piper。開發者通過 CitC 瀏覽和同步 Piper 上的文件，但是編輯和修改是在自己工作區，里面只保存有變動的文件（一個工作區一般不超過10個文件）。CitC 帶有云儲存機制，每個工作區就是云上的一個目錄。通過代碼評審以后，這些文件才從 Citc 合并進 Piper。

2.5 主干開發

Google 采用”主干開發”（trunk-based development）。代碼一般提交到主干的頭部。這樣保證了所有用戶看到的都是同一份代碼的最新版本。

“主干開發”避免了合并分支時的麻煩。谷歌一般不采用分支開發，分支只用來發布。大多數時候，發布分支是主干某個時點的快照。以后的除錯和功能增強，都是提交到主干，必要時 cherry-pick 到發布分支。與主干長期并行的開發分支，在谷歌極少見。

由于不采用"分支開發"，谷歌引入新功能，一般在代碼中使用開關控制。這避免了另起一個分支，也使得通過配置切換功能變得容易，一旦新功能發生故障，很容易切換回舊功能。等到新功能穩定，再徹底刪除舊代碼。谷歌有類似A/B測試的路由算法，評估代碼的表現，由于存在配置開關，這種測試很容易實現。

2.6 代碼評審

所有代碼合并進倉庫之前，都必須進行代碼評審。大部分評審對所有人開放，任何谷歌員工都可以對代碼提意見或者提交變動。

代碼評審的依據是《Google 代碼風格指南》。谷歌有一個叫做 Critique 的工具，可以查看每一行代碼的歷史演變。

2.7 自動測試

評審完成后，會自動運行測試。通過測試以后，代碼就合并進了 Piper 倉庫，整個過程不需要人工干預。

三、單一代碼倉庫的優點

（1）統一的版本

整個公司的代碼，有統一的版本和路徑，不存在找不到文件的最新版本這樣的問題。

（2）廣泛的代碼共享和復用

任何人都可以瀏覽和使用全公司的代碼，這大大促進了代碼的共享和復用。

（3）簡化的依賴管理

如果你是庫文件或者 API 的作者，因為所有人的代碼都在一個庫里面，所以很容易找到依賴你的所有下游代碼。

每當代碼變動，所有依賴你的代碼都會自動構建。如果有大量的構建失敗，那么系統會自動撤銷這次提交。這樣也保證了所有代碼依賴的都是最新版本，避免依賴不同的版本所導致的沖突。

另外，由于代碼的邊界很清楚，所以不會發生循環依賴。而且，API的作者也很容易發現，別人怎么使用他的API。

（4）原子性變動

由于每次代碼變動所導致的影響，都在一個倉庫里面，所以都屬于原子性的變動。因此，很容易撤銷，或者預先測試它所造成的影響。

為了防止錯誤提交，谷歌引入了”預提交”（即在提交之前，先分析一下依賴它的代碼是否會構建失敗）。

（5）大規模代碼析構

單一代碼倉庫為查找和分析代碼，提供了巨大的方便。

Google的靜態分析引擎 Tricorder 定時運行，對代碼進行分析。比如，C++ 11 標準公布以后，很容易找到所有需要改進的變量聲明語句，進行性能優化。該引擎還對許多錯誤提供"一鍵修正"的功能，同時產出大量的統計數據。

此外，編譯器團隊也會對不同語言的所有代碼進行分析，找出不合理的代碼和過時的API。

單一代碼倉庫的缺點

單一代碼倉庫的主要缺點是，所有工具都必須自己寫，因為市場上沒有能夠管理這種規模的代碼倉庫的軟件。

總結

單一代碼倉庫，適合提倡透明開放的大型軟件公司，不適合小公司和有大量私密代碼的公司。

原文：

http://m.cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext

————

編輯?∑Gemini

?來源：算法愛好者

?泰勒定理的奇聞軼事

?丘成桐：漫談微分幾何

?Leibniz 如何想出微積分？（一）

?線性相關和秩的物理意義

?數學史上你認為最丑陋的公式是什么？

?陶哲軒談什么是好的數學

?田淵棟：數學的用處（下篇）

?你絕對沒想過原來數學家這么流氓，一言不合就進行暴力證明

?世界上最牛的五篇博士論文

?數學中有哪些巧合讓人眼前一亮？

?算法立功！清華畢業教授美國被搶車，警察無能為力自己用“貪心算法”找回

?學術史上的奇文：怎樣用數學抓獅子

?臺大教授的反思：最難的一課 我們卻沒教給學生

?麻省理工學院(MIT)研究生學習指導—— 怎樣做研究生

?分享 數學，常識和運氣 ——投資大師詹姆斯·西蒙斯2010年在MIT的講座

算法數學之美微信公眾號歡迎賜稿

稿件涉及數學、物理、算法、計算機、編程等相關領域，經采用我們將奉上稿酬。

投稿郵箱：math_alg@163.com

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的Google 为什么把几十亿行代码放在一个库的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。