使用大型存储库
Git 是广为采用和建议的出色版本控制系统，但在处理大型存储库时，应注意一些问题。
在分布式版本控制系统中，尽管拥有存储库的本地副本是有效的，但当面对大型存储库时，这可能成为一个重大问题。
例如，Microsoft将包含 300 GB 以上数据的存储库从内部系统迁移到 Git 时发现此问题。
为什么存储库变得很大
大型存储库有两个主要原因：
- 悠久的历史
- 大型二进制文件
浅表克隆
如果开发人员不需要其本地存储库中的所有可用历史记录，则一个不错的选择是实现浅表克隆。
它在本地开发系统上节省空间，以及同步所需的时间。
可以指定要执行的克隆的深度：
git clone --depth [depth] [clone-url]
还可以通过筛选分支或仅克隆单个分支来减少克隆。
适用于 Git 的 VFS
适用于 Git 的 VFS 有助于处理大型存储库。 它需要 Git LFS 客户端。
典型的 Git 命令不受影响，但 Git LFS 适用于标准文件系统，在需要服务器中的文件时，在后台下载必要的文件。
Git LFS 客户端作为开源发布。 协议是一个简单的协议，包含四个终结点，类似于 REST 终结点。
有关大型存储库的详细信息，请参阅：使用适用于 Git 的大型文件 和 虚拟文件系统：在企业规模启用 Git。
标量
标量是一个可用于 Windows 和 macOS 的 .NET Core 应用程序。 使用适用于 Git 的工具和扩展，允许非常大的存储库最大程度地提高 Git 命令性能。 Microsoft将其用于 Windows 和 Office 存储库。
如果 Azure Repos 托管存储库，则可以使用 GVFS 协议克隆存储库。
它通过启用一些高级 Git 功能来实现，例如：
- 部分克隆： 通过立即不下载所有 Git 对象来缩短获取工作存储库的时间。
- 后台预提取： 每小时从所有远程下载 Git 对象数据，从而减少前台 git 提取调用的时间。
- 稀疏签出功能： 限制工作目录的大小。
- 文件系统监视器： 跟踪最近修改的文件，并且无需 Git 扫描整个工作树。
- 提交图： 加速提交遍历和可达性计算，从而加快 git log 等命令的执行速度。
- 多包索引： 可跨多个包文件快速查找对象。
- 增量重新打包： 使用多包索引将打包的 Git 数据重新打包为较少的包文件，而不会中断并发命令。
注意
我们会在新的 Git 版本发布时，更新 Scalar 自动配置的功能列表。
有关详细信息，请参阅：