超越 GVFS：更多 Git 大存儲庫的優化細節

在過去的幾年中，微軟一直將整個公司業務轉移到基於Visual Studio Team Services的現代工程系統中，並使用 Git 作為版本控制系統。對於微軟中的許多項目來說，這是沒有問題的，因為：Git主頁中如此描述：

Git 為 Linux 內核而生，這意味著它從一開始就必須能夠有效地處理大規模代碼倉庫。

而且 Git 確實對 Linux 內核的項目進行了非常有效的處理，這對於一個開源項目來說確實是相當大規模的。它在 HEAD 中包含6萬個文件，其歷史記錄跨度 12 年。

但對企業項目而言：6萬個文件並不算多。

我所工作的存儲倉庫，其中包含了 Visual Studio Team Services 的代碼庫，擁有125,000個文件，比它的兩倍還大。而在微軟，這只能算是「中等規模」。當我們談論一個大規模的源碼樹時，我們討論的是：Windows，它的體量高達 350 萬個文件。這包括創建 Windows 構建所需的源代碼、測試和構建工具，以及創建了整個操作系統的 ISO。

這起初聽起來很瘋狂，但真的不用太過驚訝。對比下 Linux 內核，這 6 萬個文件僅僅用於構建一個內核（和相關模塊），該內核必須能夠載入到你的機器的 RAM 中。我使用的內核 —— stack Ubuntu 16.04 鏡像文件——是 7 兆位元組，並附帶另外 200 兆位元組的模塊數據。

Linus 曾開玩笑說內核已經變得「臃腫而龐大」。當然，這個 200 兆位元組比 90 年代初期要大得多，當時內核不得不放到一個軟盤上，而不得不為一個只有4 兆位元組 RAM的機器適配，同時確保剩下足夠的空間來驅動該系統。

而 Windows 10 呢? 那是 4GB 大小的 ISO 鏡像。

由於所有Windows——內核、庫，應用程序——是一起發布的，它們也被一起版本化，在一個大的「monorepo」中。 當計劃將 Windows 遷移到 Git 時，我們考慮將代碼庫分解成許多較小的存儲庫，並將它們按照 Git 子模塊或 Android 的 repo 系統進行分層處理。 但有時候 monrepos 是最簡單的協作方式。

@xjoeduffyx即使組件化有效，我還是去用 monorepo。高效協作至關重要:https://t.co/xt03PCGh3D

— Joe Duffy (@xjoeduffyx)February 3, 2017

不幸的是，像 Windows 這樣龐大的 monorepo 有一個問題，Git 並沒有處理好過如此大的存儲庫的先例。

在過去幾年中，我們一直在努力調整 Git 來自適應處理像 Windows 存儲庫這樣真正大型的 monorepos。這項工作的最大部分——到目前為止，是 GVFS，Git Virtual Filesystem（Git虛擬文件系統）。GVFS 允許我們的開發人員在 clone 時不用把 350 萬個文件全部下載，而是在開發人員工作的源代碼樹的較小部分中進行頁面訪問。

Saeed Noursalehi 正在撰寫一系列有關GVFS的文章，以及如何讓我們讓 Git 變得可伸縮。 這是非常高級的功能，絕對能夠用於處理 Windows 大小規模的源代碼樹，但它並不全是我們在處理 Windows 存儲時必須做的全部工作。將這麼多文件放在單個存儲庫中對 Git 的數據結構和存儲機制來說是很大的挑戰，即使是在不是所有的文件都實際保存於工作目錄中的情況下。

雖然 GVFS 是像 Windows 團隊這樣的巨型存儲庫的重要解決方案，但我們所做的這些額外工作將幫助常規的 Git 用戶獲得更多的標準存儲庫大小。

索引

索引（也稱作「暫存區」或「緩存」）是 Git 倉庫的核心數據結構之一。它包含倉庫中每個文件的列表，並且幾乎所有涉及工作目錄的操作都會查閱它。索引將填充您在克隆倉庫時以及切換分支時檢出的路徑列表。當您運行 status 以確定哪些文件處於 staged 和 modified 的狀態，它將被審查。並且當您進行合并時，新的樹（以及所有衝突）都將存儲在索引中。

由於它用於這麼多操作，所以訪問索引必須很快，即使它包含 350 萬個文件。Git 保持索引訪問速度的一種方法是通過保存路徑列表的排序，以便您可以通過二進位搜索來查找您需要的內容。

但是保存此列表的排序依然是有開銷的。我們注意到大型存儲庫中的一個痛點是切換分支：這種日常的操作需要 30 秒到一分半鐘不等。顯然，檢出操作中把文件傳輸到磁碟上的這個步驟是最慢的，不過如果我們再深入探究下去，會驚奇地發現，我們同樣也花費了大量的時間去創建新的索引，以便它包含新分支中的文件列表。對於我們要插入索引的文件，我們會嘗試找出我們要插入的文件。這意味著系統是通過對索引的二份查找來找到新路徑的位置的。

在邏輯上充分說明，列表文件在我們插入時就已經被排序了。因此，我們會忙於在每個路徑上執行一個 查找，這樣做的目的只是為了去發現我們要在索引末尾附加的路徑。因此我們改變了這個步驟，跳過二分查找，只做追加。

這個看似很小的優化在 調用中節省了 15-20% 的時間。事實證明，當 n 是 350 萬個文件時， 變得相當緩慢。

當我們在查看索引時，我們觀察到另一個類似的小操作：文件的校驗和驗證。當 Git 客戶端編寫索引時，它們計算其內容的 SHA-1 散列，並將其附加到文件的末尾。這使得 Git 在重新讀取索引時會比較該哈希值，以確保它不會被微小的磁碟損壞所破壞。

對於小型的存儲庫和適用於 Linux 內核大小的存儲庫，這種計算基本上不是問題：計算 SHA-1 散列時讀取索引耗時很低。但是對於像 Windows 這樣的大型存儲庫，散列索引的內容幾乎和解析它一樣耗時。

我們首先將散列計算工作分解成後台線程，結果非常好。但是，最終，在每個操作上驗證散列通常是不必要的，因為校驗和檢測到這種微妙的文件損壞是非常罕見的。 （雖然並不是完全沒有聽說過）。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！