使用大型存储库

• 4 分钟

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 数据重新打包到较少的包文件中，且不会干扰并发命令。

有关详细信息，请参阅：

• microsoft/scalar：Scalar。
• Scalar 简介：面向大众的大规模 Git。