Git虚拟文件系统GVFS

原文见：https://blogs.msdn.microsoft.com/visualstudioalm/2017/02/03/announcing-gvfs-git-virtual-file-system/?from=timeline&isappinstalled=0

在微软有着很多不同规模的团队，大部分团队都正在或者准备使用Git。在大多数情况下，Git客户端和在团队服务中的Git repo能够使他们工作的更好。然而，我们仍有少数团队存在着大小异常的代码repo。比如，Windows代码库有着超过超过350万个文件，占用了超过270GB的空间。Git客户端并不是为了如此多的文件或内容所设计的。你可以看到当你运行“git checkout”时，它会花费3个小时执行这个操作，甚至执行一个简单的“git status”操作都需要花费10分钟。假设我们能够执行“git clone”操作，这将花费超过12个小时。

即使是这样也不能阻止我们，我们都是Git的粉丝。这样是为什么我们一直在努力尝试让Git客户端能够支持任何规模的repo。现在，我们来介绍GVFS（Git Virtual File System Git虚拟文件系统）。GVFS将repo下面的文件系统虚拟化，使他看起来像是存储在repo里面的所有文件，但是只有当某个文件第一次被打开的时候才会被下载。GVFS也动态的管理类似于checkout和status等操作中真正有效的数量，因为任何未被合并的文件都可以被安全地忽略。由于我们在文件系统的任何层级都做了这样的操作，因此你的开发工具或者构建工具并不用进行任何的改动！

在一个如此巨大的repo中，开发者不会构件整个源文件。取而代之的是，他们通常会下载最近一次的离线构件输出的文件，并且只构件与他们所修改的地方相关的一小部分。因此，即使在repo中存在着超过300万个文件，一个典型的开发者只需要下载它们需要使用的大约5-10万个文件。

使用GVFS，这意味着他们现在有一个更易于管理的Git体验：clone只需要花费几分钟而不是超过12小时，checkout只需要花费30秒而不是2-3小时，status只需要4-5秒而不是10分钟。同时我们也正在努力让他们变的更好。（当然，权衡是他们的第一次构建需要更长的时间，因为它必须下载它正在构建的每个文件，但后续构建不回比正常情况慢）

虽然GVFS的开发仍在进行中，我们很激动的宣布我们开源了客户端的代码并且将代码放在了https://github.com/Microsoft/gvfs上面。请随意尝试，但请注意，它仍然依赖于一个预发布文件系统驱动程序。驱动程序二进制文件也可以作为NuGet软件包预览，最好的办法是先在虚拟机中使用GVFS，而不是直接在任何生产环境中使用。

除了GVFS源之外，我们还对Git进行了一些更改，以便在GVFS支持的repo上正常工作，这些源位于https://github.com/Microsoft/git。 最后，GVFS依赖于任何服务可以实现的协议扩展; 该协议位于https://github.com/Microsoft/gvfs/blob/master/Protocol.md。