為何Google、微軟、華為將億級原始碼放一個倉庫？從全球最大程式碼管理庫說起...

為什麼要做 VFS For Git？

鄒欣回憶，在將程式碼遷移到 GVFS 前，微軟曾使用多個主要的程式碼管理平臺，包括 SLM, Source Depot （上世紀 90 年代開始）、TFS 的原始碼控制 TFVC （2006 年開始）。直到 2017 年，微軟用三個月的時間完成程式碼遷移到 Git，並推出了 Git 的變種，針對特大 repo 的 GVFS，並沿用至今。

 

GVFS 是一個 Git 虛擬檔案系統，全稱為 Git Virtual File System，允許 Git 處理 TB 規模的程式碼庫，比如 270 GB 的 Windows 程式碼庫。GVFS 的 V 就是 Virtual（虛擬），它解決了Git 原來的設計缺陷（每個客戶端都有所有版本的程式碼），而是用虛擬檔案來代替那些本地用不著的檔案， 大大減少了檔案傳輸和本地機器儲存的壓力，讓微軟內部技術人員可以進行高效協作。

 

一段小插曲是，GVFS 從釋出之初就引起了爭議，原因是 GNOME 專案的虛擬檔案系統也叫 GVfs，而 GNOME 的 GVfs 最早釋出於 2006 年，之後的教程、文件、論壇都沿用這個名字。在微軟的 GVfs 專案釋出後，很快超過了 Gnome GVfs 專案的搜尋排名，且由於二者都與虛擬檔案系統有關，導致使用者在查詢資訊時容易出現混淆。於是，很多開發者要求微軟改名，經過一番周折後，微軟終於在 2018 年將 "GVFS" 專案的名字改為 "VFS For Git"。

 

鄒欣表示，當時微軟將程式碼遷移到 Git 主要是為了統一微軟百花齊放的內部工具，並沒有一個絕對好的選擇，領導團隊選擇了 Git,  但從現在的結果來看，這是一個比較好的選擇。如今，微軟仍然在對 Git 系列的工具做改進，也把改進回饋到 Git 社群。

 

現在，VFS For Git 已經是微軟內部統一的工具，同時被其他大型企業採用：https://vfsforgit.org/ 

 

VFS For Git 在 GitHub 上也已開源：

 

GitHub開源地址：https://github.com/microsoft/VFSForGit

單一自研程式碼管理倉庫是最好的選擇嗎？

 

除了微軟，我們發現，很多大公司的程式碼託管已經向自己內部開發的版本控制系統遷移，比如 Google 就把使用不同語言編寫的超過 10 億檔案，近百 TB 原始碼都存放在自行開發的版本管理系統 Piper 中，只當專案開源且需要外部協作時，才會使用業界流行的 Git。（詳見文章《》）

 

再如華為的內源（Inner Source）平臺，承載著華為 1100 億原始碼、60 萬+ 程式碼倉庫、每天 60 T 的下載容量、1 萬次/秒的高峰併發下載。

 

這是否說明在大公司中流行的單一倉庫就是最好的做法？這些公司在選擇採用程式碼託管方式時需要考慮哪些不同的問題？

 

鄒欣對 AI科技大本營進行解釋，在他看來，用 GVFS 也可以建立各種獨立的倉庫。用一套工具有利於公司內部進行程式碼共享，讓人員流動、程式碼複審、改進工具變得更簡單，效率提高。

 

其次，大公司有很大量的程式碼，很長的歷史和很多工具，如果貿然選擇一個新工具就會出現以下問題：

 

a) 一些市面上的工具並不是為大規模程式碼設計的，處理不了大量程式碼， 我們以前用第三方的程式碼分析工具， 結果處理 Office 的程式碼的時候，自己崩潰了，因為 Office 的程式碼量太大，這個工具的開發者沒有為如此大的程式碼設計軟體。

 

b) 很多工具在歷史中不斷演化， 有自己獨特的特點，很多和企業內部的某些特殊需求有關，外部工具很難都實現這樣的功能。

 

很多工具聯合在一起，會形成了一個工具的生態，但如果只改變一個工具，讓其他的工具變得不相容， 那整個團隊的很多工作流就會出現問題。

 

此外，鄒欣表示，程式碼託管與 AI 結合是未來發展方向。例如，這種結合會告訴你昨天晚上籤入程式碼有問題， 或者簽入程式碼和某個其他團隊的程式碼相似，建議重用。或者告訴你簽入的程式碼是從網上拷貝來的， 而且把原來程式碼中的 bug 也拷貝過來了。

 

最後，AI 科技大本營引用此前微軟雲開發服務副總裁 Brian Harry 於 2017 年發表的一篇博文內容，在微軟推出 VFS For Git 三個月後，他分享了該平臺的更多細節及其未來目標，包括擴大開放原始碼並改善其在 Microsoft 上的執行表現，想要了解  VFS For Git 更詳細的資訊，不妨仔細研讀一下這篇文章：

 

用 Git 管理 Windows

在過去三個月中，我們已經基本完成了向 Microsoft Windows 團隊推出 Git/GVFS 的工作。

Windows 程式碼庫大約有 350 萬個檔案，當遷入 Git 版本庫時將產生 300GB 的儲存量。此外，Windows 團隊約有 4000 名工程師，這個龐大的工程師系統每天都要處理成千上萬次驗證請求，在 440 個分支裡進行 1760 次實驗性變更。在所有的三個維度（檔案計數、版本庫大小和活動）都是令人生畏的擴充套件挑戰，這些因素夾雜在一起使得這個工作變得異常困難。在遷移到 Git 之前，這些資料儲存在 40 多個不同的倉庫裡，我們需要跨越多個庫進行操作。

在我三個月前撰寫文字的時候，我們將所有程式碼都儲存在一個 Git 版本庫裡，幾百名工程師在很小一部分日常構建（<10%）中使用並對它進行了測試，自此我們在整個工程團隊裡掀起了波瀾。

第一次也是最大的一次事件發生在 3 月 22 日，當時我們向擁有約 2000 名工程師的 Windows OneCore 團隊推廣了 Git。他們週五在 Source Deport 上工作，週末回家，然後週一上班時體驗 Git 的效果。我們團隊中的每個人在週末時都屏住呼吸，祈禱週一上班時不會被一幫丟了程式碼的暴怒工程師圍毆。但事實上，Windows 團隊在備份方案方面做的非常出色，也謝天謝地我們並沒有使用到這些方案。

老實說我對於事情進行的那麼順利還是很驚訝的。毫無疑問我們遇到了一些問題，由於龐大的團隊規模和工作性質的問題，Windows 通常會在各個分支部門之間進行大合併，導致每個小變更都會引發多個部門的共同改動。第一週時我們發現我們提出需求和解決矛盾的 UI 根本無法應對這麼大規模的共同變動。我們手忙腳亂地把列表虛擬化並逐步獲取資料，以便 UI 不至於忙到掛起。我們在幾天之後解決了這個問題，總體來說，這周的體驗比我們想象的要好得多。 

我們衡量成功的方法之一是在工程師團隊中進行滿意度調查。除了核心問題“你對它滿意嗎？“，我們還提出了一些小問題。兩週之後我們第一次調查結果如下：

             

從上往下分別為：非常滿意，還算滿意，不太滿意，非常不滿意

我們沒有為這個調查結果開個派對慶祝，但作為一個歷經千難萬險不斷學習新技術的開發團隊，我們對這個進步還是非常開心的。2000 個人的團隊只有 251 個人回覆了我們的調查，我們歡迎更多的人給予我們評價。 

另外一個衡量成功與否的方法是檢視“工程活動”以調查工程師們是否完成工作。例如，我們計算了官方分支的使用“簽到數”，團隊中有一半工程師使用 Source Depot ，另一半遷移到了 Git 上，因此我們對一段時間內的綜合活動進行了研究。在下面的圖表中，Source Depot 的簽到數大幅下降，而從 Git 輸出的請求大幅躍升，但兩者的綜合保持相對一致，我們認為該資料表明這個系統正在無阻執行。

              標題為 每日檢出量

4 月 22 日，我們邀請新一批約 1000 名工程師加入測試隊伍，5 月 12 日我們又邀請了 300-400 名。每一批新加入的工程師都差不是相同的工作模式，目前 Git 上有 3500-4000 名微軟工程師。其餘的小組正在按時完成工作並計算遷移計劃的最佳時間點，我預測接下來的幾個月裡應該能完成整個工程師團隊的遷移。

整個系統的規模令人驚訝，讓我們看一些數字...

- 過去 4 個月裡，有超過 250000 個可以追溯的 commit

- 平均每天 8421 次 push

- 平均每個工作日 2500 次 pull 請求和 6600 個回覆的人

- 4352 個活躍主題分支

- 每天 1760 個由官方搭建（build）的測試

如你所見，這個巨大的版本庫里正在進行著大量的活動。

GVFS 的大規模效能

在滿意度調查裡，有部分工程師對這個系統表示不滿。我們有大量資料來解釋原因—-從部分工具尚不支援 Git 到學習新知識的沮喪感。但我想深入研究一個首要問題：Git 本身的效能。我們知道當我們推出 Git 時還有很多工作尚未完成，還有很多新東西不斷加入。我們跟蹤一些Git關鍵操作的表現。以下是遙測系統從大約 3500 名工程師裡收集到的 GVFS 使用資料。

              

表中的目標代表最糟糕的情況，如果系統的執行時間高於此值則無法使用，這並不是“我們希望系統在這個範圍”的值。對比前7天和後7天在80%位點上的變化量，所有的數值都在變慢。

如果在工作開始之前使用 “Vanilla Git”，許多指令可能需要30分鐘到幾個小時都無法完成。為了一個只需要20秒的指令等待10-15秒是一個很糟糕的事情。

當我們第一次推出它時，結果要好得多。事實證明，隨著時間流逝，工程師從程式碼庫裡學習的越來越多，從而導致了我們稱為“過度飽和”的問題。最終工程師只是獲得了一堆偶爾使用、不再進行修改的廢檔案。這導致了效能的逐漸下降。人們可以將這些檔案加入清理，但這很麻煩，也很少人這麼做，久而久之系統越來越慢。

這啟發了我們開始另一輪稱為“O（modified）”的效能優化，它將許多關鍵指令更改為與使用者修改過的檔案數量成正比。我們將在下週把這些修改推廣到團隊裡，所以目前還沒有統計資料，但參加早期測試的使用者普遍反映良好。

我沒有全部資料，但我從上個表格中選擇了一些事例並把表現結果複製到“O 飽和（hydrated）列”，使用下週將要推出的效能增強後得到的執行結果列為“O 改動（Modified）”。所有數字都以秒為單位。從表中我們可以看到效能有了全面提升—有些很小，有些大約2倍，狀態快了將近5倍。我們非常樂觀，這些改動將提高使用者體驗。雖然我永遠不會滿足（直到狀態低於1秒我才會滿意），但這個進步還是讓我開心。

              

影響表現的關鍵因素還有分散式團隊。Windows 的工程師遍佈全世界—美國、歐洲、中東、印度和中國等。長距離大範圍拉取資料是一個問題。為了解決這個問題，我們花大力氣構建了一個用於 GVFS 的 Git 代理解決方案，該方案讓我們能夠“在邊緣”快取 Git 資料。我們還在高峰負載期使用 Visual Studio 團隊服務分擔了大量流量，避免損害使用者體驗。總的來說，我們在全球範圍內有 20 個 Git 代理。

讓我舉個例子，Windows 團隊服務賬戶位於美國西海岸的 Azure 資料中心。在這個地方，Windows 工程師克隆速度的 80% 位點為 127 秒。這是由於我們大部分微軟工程師都在Redmond，這個資料主要是由他們主導。我們在北卡羅萊那州的辦公室（距離我們很遠並且寬頻較低）進行了測試。不使用代理伺服器的情況下，從北卡羅來納州進行克隆需要25分鐘，而在配置了代理伺服器並保持更新的狀態下，該過程僅花費了 70 秒（比 Redmond 更快，因為 Redmond 團隊比使用代理伺服器，他們必須通過網路跨越數百英里到達 Azure 資料中心）。從 70 秒到 25 分鐘，效能提升了將近 95%。

總體來說，搭載 GVFS 的 Git 完全可以在大規模情況下有效地被使用。同時，我們做了大量工作使工程師們對它的表現表示“滿意”，但在我們完成整個專案前，我們仍然有很多可以改進的地方。 

開發者試用 GVFS 

GVFS 是一個開源專案，任何人都歡迎來嘗試一下。你只需要下載和安裝，建立一個帶有 Git 版本庫的 Visual Studio 團隊服務賬號就可以開始使用。自從我們最初發布 GVFS 以來，我們已經取得了很多不錯的進步，一些主要的改進包括： 

我們對已經發布的程式碼庫進行定期更新—正朝著“公共開發”邁進。截至目前，我們所有的最新變動（包括O 改動（modified）的改進）均已釋出到公共庫裡，我們將定期對其進行更新。

GVFS 依賴於名為 GVFIt 的 Windows 檔案驅動系統。目前為止，我們提供的該驅動程式還正式試用（因為還有很多進行中的工作），顯然這導致很多測試衝突。今天我們釋出了簽名版本的 GVFIt 並消除了這個問題（例如使用者不再需要禁用 BitLocker 後才能安裝它）。儘管我們有試用的 GVFIt 驅動程式，但這並不是一個可維持的交付方式，我們希望這個功能可以組合進未來的 Windows 發行版裡。

從我們在 Git Merge 的演講開始，我們針對 Git 和 GVFS 擴充套件問題與更廣泛的Git社群進行了互動。在與其他大型科技公司（例如谷歌和 Facebook ）進行了對話時，我們發現他們也面臨著類似的挑戰，所以向他們分享了經驗與方法。我們還與一些熱門的 Git 客戶合作，以確保他們在 GVFS 上的順暢體驗，包括 Atlassian Source Tree、Tower Git 團隊、Visual Studio、Git for Windows 等。

總結

我們將繼續努力把 Git 擴充套件到足以支援大型團隊的程式碼庫，從第一次記錄這些工作已經過去了三個月，這期間發生了很多事，我們團隊已經...

- 成功將其推廣給3000個微軟工程師

- 進行了一些重大的效能改進並引入了 Git 代理

- 用最新程式碼更新了開源專案，並開始歡迎外部幫助

- 提供了簽名版本的 GVFIt 驅動並降低了它的使用難度

- 與社群合作，為熱門工具（SourceTree、Tower、Visual Studio等）提供支援

- 發表了一些文章分享我們對 Git 和 GVFS 使用技術的更多見解

不論對微軟團隊還是我的團隊，這都是一個激動人心的改變。這是一個極具挑戰的專案，我為進步歡呼，也為剩下的工作頭疼。目前，Visual Studio 團隊服務是唯一支援 GVFS 協議增強功能的後端實現。如果市場反應夠強，我們會與 Team Foundation 伺服器和其他 Git 服務洽談新增支援。

 

相關連結：

https://devblogs.microsoft.com/bharry/the-largest-git-repo-on-the-planet/

2019 中國大資料技術大會（BDTC）再度來襲！豪華主席陣容及百位技術專家齊聚，15 場精選專題技術和行業論壇，超強幹貨+技術剖析+行業實踐立體解讀，深入解析熱門技術在行業中的實踐落地。

即日起，限量 5 折票開售，數量有限，掃碼購買，先到先得！

推薦閱讀