Azure DevOps Git仓库容量上限及大文件管理方案咨询

我们有一个采用Git LFS的单仓库，通过git-sizer检测的代码库数据如下（注：git-sizer不显示Git LFS对象）：

当前用于集成测试、数据测试及单元测试的大型数据集（规模从几KB到1GB不等）存储在独立网络驱动器上，存在以下问题：

• 构建代理必须访问内部网络，无法使用Azure DevOps托管构建代理；
• 网络驱动器与Git仓库不同步，自行搭建的文件版本控制机制偶尔出错。

1. Git LFS 对克隆/拉取/推送操作的影响与优化 #

克隆操作 #

默认情况下，Git LFS会在克隆仓库时同步所有LFS对象，针对大文件较多的场景确实会耗时较长。可以通过以下方式优化：

• 使用git lfs clone --no-checkout先克隆仓库的Git元数据和LFS指针，再根据需要检出特定文件或目录；
• 结合Git的部分克隆功能：git clone --filter=blob:none，只克隆分支结构和文件指针，之后再通过git lfs pull --include="path/to/test/data"按需拉取指定的LFS文件。

Fetch/Pull操作 #

日常的git fetch或git pull操作中，Git LFS只会拉取变更的LFS对象，不会重复下载已存在的本地对象，因此除了首次拉取大文件外，后续操作的耗时和普通Git仓库差异不大。可以通过配置lfs.concurrenttransfers参数增加并发下载数，提升大文件拉取速度。

Push操作 #

推送时会先将LFS对象上传到Azure DevOps托管的LFS存储服务，再提交Git指针到仓库。流程和普通Git推送一致，但大文件上传耗时取决于网络带宽。建议分批推送大型测试数据，避免单次推送过多大文件导致失败。

2. Git Scalar 的功能与适用场景 #

Git Scalar并非类似OneDrive的按需下载云存储，它是微软针对超大型Git仓库推出的性能优化工具，核心价值包括：

• 自动配置Git的高性能参数：比如调整增量打包策略、并行操作数、缓存机制等，针对性解决大仓库的性能瓶颈；
• 支持部分克隆与稀疏检出：可以只克隆仓库的部分目录或文件，大幅减少首次克隆的体积和时间；
• 后台预取与维护：自动预取常用分支的更新，优化后续操作的响应速度。

对于你的场景，Git Scalar可以和Git LFS配合使用：用scalar clone初始化仓库，配置稀疏检出只拉取当前需要的测试数据目录，结合LFS管理大文件，既能解决克隆耗时问题，又能保留版本控制的一致性。

3. Azure DevOps 仓库容量限制与实践 #

容量限制说明 #

• 公共项目：无硬性容量上限，但微软官方建议单仓库不超过250GB，超过后仓库的克隆、拉取等操作性能会明显下降；
• 私有项目：每个组织有基础存储配额（基础版用户默认5GB），超出后可付费购买额外存储，单仓库同样建议控制在250GB以内。

可行实践方案 #

• 拆分仓库：将测试数据按模块、测试类型或版本拆分为多个独立的Git LFS仓库，避免单仓库体积过大；
• 清理冗余数据：定期用git lfs prune清理本地未使用的LFS对象；在Azure DevOps仓库中删除废弃分支及对应的LFS对象，释放存储空间；
• 归档历史数据：将不再活跃的旧测试数据归档到单独的历史仓库，当前仓库只保留常用的活跃数据。

内容的提问来源于stack exchange，提问作者msedi