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