原文鏈接： https://www.infoq.com/news/2017/02/GVFS
InfoQ翻譯：http://www.infoq.com/cn/news/2017/02/GVFS?utm_source=infoq_en&utm_medium=link_on_en_item&utm_campaign=item_in_other_langs
雖然Git被廣泛認為是最好用的版本管理軟件，但它并不是完美無暇的。它的一些缺陷可以通過第三方的工具來彌補，但微軟公司在嘗試從本地將300GB的代碼倉庫遷移到Git時，卻發現整個代碼倉庫復制的方式存在著致命的問題。為了解決這個難題，微軟自行開發“Git虛擬文件系統”（GVFS）。
在2000年前后那段時間，微軟內部主要使用的是一個名叫Source Depotde 系統，它是Perforce的一個分支。后來越來越多的團隊開始轉向使用TFS中的版本控制軟件TFVC。但那些龐大的團隊卻無法讓所有的人都同時將代碼轉出Source Depot，以及另外一些團隊則在使用TFS的同時，需要通過很多第三方工具和非TFS團隊協作。
為了簡化這樣復雜的工作環境，微軟決定將所有團隊統一成使用Visual Studio Team Services （即云端的TFS）來規劃工作，自動構建以及代碼管理，并選擇了使用在VSTS搭建Git的方案來實現代碼版本控制。
為什么選擇Git？在微軟工作的reddit 用戶 jeremyepling提到了以下三個原因：
1.Git和GitHub幾乎已經提供了開源軟件開發的標準形式。微軟在開源軟件開發中作出了很多嘗試，并且我們也需要像TFS 和Team Service這樣屬于自己的DevOps工具來更好的管理那些工作流程。
2.我們一個獨立的版本控制系統來管理微軟的上上下下。標準化的流程使得大家可以更好的兼顧多個工程并且更專注與開發。由于開源軟件已經和Git緊密聯系，并且我們做了很多開源的工程，這一切讓Git瞬間成為主流。
3.我們想更好得支持開發社區和DevOps用戶。Git對于當前的版本控制系統來說無疑是最主流的。
但這樣還有些問題，Brian Harry 解釋道：
事實上還存在許多反對選擇Git的觀點，其中一個就是懷疑在微軟這樣的代碼規模下，Git未必會有良好的表現。并不是所有的公司都和我們一樣有如此龐大的代碼規模。尤其是Windows和Office這兩個項目，原始代碼體積非常巨大。成千的工程師，上萬的文件，以及持續構建著工程的上千臺機器，實在是難以想象的規模。生命一下，我在這里提到的Windows包括了運行在PC，手機，服務器，HoloLens，Xbox，IOT上的系統。Git作為一個分布式版本管理系統，他會將整個倉庫和所有的歷史操作復制到每個人的本地機器上。對Windows這個工程做這樣的操作實在是有點搞笑（是的我們已經被人笑話過很多次了）。TFVC和Source Depot都小心翼翼地優化這龐大的代碼結構和團隊之間的關系，Git則從來沒有考慮過這樣的問題，所以很多人認為Git并不能正常的應用在這么大的工程上。
將Windows代碼庫拆分成合適大小的子庫并不是特別的合適。也許他們在之前就開始著手拆分的話，現在可能已經成功了。但是在如此龐大和年代救援的代碼面前，再想回到過去并將它拆分已經是不可能的了。Brian繼續道：
這意味著我們必須要增強Git所能處理的規模，讓它可以在現有的代碼和成千上萬的文件讓上千個開發者可以正常工作。話說回來，即便是Source Depot也沒有規模大到直接覆蓋整個Windows代碼庫。它是被分成40多個depots之后，再通過加上一個抽象曾來使得我們在大多數情況下可以將這些堪稱一個整體。然而這樣的抽象并不完美而且也帶了一些問題。
在各種嘗試失敗之后，微軟開始開發Git虛擬文件系統：
我們嘗試用一種方法來將Git虛擬化。一般來說Git會在你克隆代碼庫的時候將所有東西都下載到本地。但如果我們不這么做呢？如果我們將存儲虛擬化，并只下載你所需要的文件呢？這樣克隆一個巨大的300G的代碼庫將變得非常快。當我們使用Git的命令或者讀寫文件時，系統則會從云端將需要的文件下載下來并存儲到本地。不過這樣做的缺點之一是你在斷網的情況下無法正常使用。如果你必須要在這樣的環境下工作，則需要嘗試“觸碰”所有的文件。對于我們這樣巨大的代碼庫，這個方法行之有效。
微軟對Git作出的貢獻
如果想讓GVFS更好的運行，那微軟必須要提升Git在訪問文件方面的性能。早前版本的Git并沒有太在意本地代碼庫的存儲性能，有時會做一些不必要的文件掃描。這就是為什么微軟在前幾年向Git的開源工程中提交了他們的性能提升代碼。
Jeremyepling 寫道：
我們微軟Git團隊已經對Git在Linux、Mac和Windows上的性能提升作出了很多貢獻。在Git的2.10版本中，我們為提升rebase的性能做了很多事，并最終使得它在Windows、MacOSX、Linux上分別提高了5、4、3倍的運行速度。
列舉一些對Git作出的改進：
sha1: 在mingw上使用 openssl sha1 https://github.com/git-for-windows/git/pull/915
preload-index: 對skip-worktree的文件不使用Istat https://github.com/git-for-windows/git/pull/955
memihash perf https://github.com/git-for-windows/git/pull/964
add: 使用 preload-index 和 fscache 來提高性能 https://github.com/git-for-windows/git/pull/971
read-cache: 在后臺線程執行verify_hdr() https://github.com/git-for-windows/git/pull/978
read-cache: 在切換分支時提高 add_index_entry 的速度https://github.com/git-for-windows/git/pull/988
string-list: 使用ALLOC_GROW macro的方式重新為 string_list申請內存 https://github.com/git-for-windows/git/pull/991
diffcore-rename: 加速register_rename_src https://github.com/git-for-windows/git/pull/996
fscache: 在 fscache 中添加not-found路徑的緩存 https://github.com/git-for-windows/git/pull/994
Git Virtual File System
Git Virtual File System (GVFS)的原型實現了一個在客戶端的文件系統和集成了GVFS功能的Git。這可以在十周年甚至更長遠的一段時間內，看作是Windows的最杰出的功能升級。當你的Git代碼庫集成了GVFS之后，普通的Git命令仍然可以正常使用，GVFS則會默默得在文件系統后臺下載你所需要的文件。
GVFS客戶端代碼的開源，可以讓任何人都有機會認識到如何實現一個Windows下的虛擬文件系統驅動。
相對應的，服務端需要實現 GVFS 協議。目前只有Visual Studio Team Services提供這樣的服務。但因為這項服務協議是開源的，所以任何服務提供商都可以實現相應的功能。同時GVFS協議也非常的簡單，只包含了四個類似REST風格的訪問端點。
