今天在微信的一个游戏群里看到有网友讲了一件有趣的事，一群开发半夜无聊，想通过版本控制系统传实况足球的安装包，然后传进项目代码库了，被运营抱怨说项目代码过大，就很乐。
然后记起好像之前看过轮子哥说 office 的代码库有 300 多个 G 的大小，当然后来也有人指出真实代码没有那么多。有朋友透露了一下 WPS 的代码仓库有 20 G 大小。
我也突然来了兴趣，想知道有没有人统计过能够查到的最大的代码仓库是哪些。于是搜了一下，发现还真的有人做过这种统计。
根据统计，google 拥有有史以来最大的代码仓库，足足有 20 亿行代码。我就按每行代码 20 字节算，也足足有 37 G 的代码量。当然这都是纯代码，还不包含其他文件以及代码文件本身的膨胀。不过 google 用的并不是 git 工具，之前 google 也公布过他们把绝大部分代码都放在一个代码仓库里1（好像 facebook 也是这么干的），所以才会有这样的规模，而且他们的代码版本控制工具是他们自己开发的 Piper，之前他们在 acm 杂志上发表过他们的做法：
在使用 git 作为版本控制工具的所有仓库里，微软的 windows 系统仓库是最大的2，据说有 350 万个文件，300 G 的大小，440 个分支。当然微软的 git 工具也是在开源的 git 工具基础上自己定制修改过的3。
windows 的团队经理还写了两篇如何使用 git 来管理这么庞大项目的心得文章：
https://devblogs.microsoft.com/bharry/scaling-git-and-some-back-story/
https://devblogs.microsoft.com/bharry/the-largest-git-repo-on-the-planet/
简单总结一下：
- 微软团队内部的代码版本管理工具之前比较混乱，亟待统一，选择 git 也是拍脑袋决定的，只不过受到越来越多人认同。
- 使用 git 的最大问题在于 windows 代码项目的规模非常的大，有几千名工程师、几百万个文件、几千台机器需要构建项目。而且 windows 的这个项目包含了 PC 、移动设备、服务器、Xbox 等等不同平台的内容，所以如果按照 git 工具的做法，clone 仓库的时候会把所有的文件跟改动记录都拉取下来，这是非常愚蠢的，因为大部分的工程师都只会关注自己用到的那一小部分代码，拉取所有代码跟改动的做法明显是不合理的。
- 鉴于上面遇到的问题，通常的做法是把 windows 这样一个庞大的代码库按照平台或模块拆分成若干个小的代码仓库，然后分别用 git 来管理。把这些小仓库用 submodule 的方式合并在一起。微软团队一开始也是这么尝试的，但半年之后发现过程太痛苦了（其实我自己正在做的项目也用到了几十个 submodule ，多个 submodule 改动大且频繁的时候确实是一件很痛苦的事情）。
- 微软后来放弃了 submodule 的方式，但又想对使用 git 的方式做透明化处理，并尽量小的对 git 工具做修改，于是做了一个 GVFS 的虚拟化文件系统来实现管理百万级别的仓库文件，简单描述起来做了两件事：
- 虚拟化了 .git 目录，对历史记录等内容做了虚拟化处理
- 对工作目录做了虚拟化 只有在真正 touch 对应的文件的时候才会真的去 git 服务器动态拉取对应所需的文件内容，其他时候只是由 GVFS 提供一个索引让 git 工具认为已经在本地拥有了对应的文件。
- 除了添加 GVFS4 的改动外，还修改了 git 的服务器程序5，主要也是两点加强：
- 加强了 git 服务器程序的打包文件方式，使得它可以仅仅只传输客户端所需的那部分内容
- 优化了 git 的命令执行过程，原生 git 的一些操作会大量扫描不需要的文件，因此去掉了那些不必要的文件扫描
windows 项目经理也给出了使用 GVFS6 的性能对比以及个人使用的一些建议跟经验：
https://devblogs.microsoft.com/bharry/the-largest-git-repo-on-the-planet/
就还蛮有意思的。