Azure DevOps Services
我们对 Azure Repos 中的 Git 存储库施加资源限制，以确保所有客户的可靠性和可用性。 通过保持数据大小和推送次数合理，您可以获得更好的 Git 整体体验。
Git 与其余 Azure DevOps Services 一起参与 速率限制 。 此外，我们还对存储库的总大小、推送以及文件和目录路径的长度施加了限制。
存储库大小
存储库不应大于 250 GB。 要检索仓库的大小，请在命令提示符下执行 git count-objects -vH ，并查找名为 “size-pack” 的条目：
D:\my-repo>git count-objects -vH
count: 482
size: 551.67 KiB
in-pack: 100365
packs: 25
size-pack: 642.76 MiB <-- size of repository
prune-packable: 83
garbage: 0
size-garbage: 0 bytes
我们建议您将存储库保持在 10 GB 以下，以获得最佳性能。 如果存储库超过此大小，请考虑使用 Git-LFS、 Scalar 或 Azure Artifacts 来管理开发项目。
Azure Repos 通过将类似文件合并到包中，不断减小 Git 存储库的整体大小并提高其效率。 对于接近 250 GB 的存储库，可以在优化过程完成之前达到 pack 文件的内部限制。 达到此限制时，尝试写入存储库的用户会看到以下错误消息：“已达到 Git 包文件限制，更新存储库时写入作暂时不可用。优化作业完成后，写入作会立即恢复。
文件不应大于 100 MB。 此限制有助于确保 Git 存储库的最佳性能和可靠性。 大文件会显著降低存储库作的速度，例如克隆、获取和推送更改。 如果您需要存储大型文件，请考虑使用 Git LFS（大型文件存储），它旨在通过将大型文件存储在主存储库外部并且仅将对它们的引用保留在存储库中来高效处理大型文件。 此方法有助于维护 Git 存储库的性能和可管理性。
推送大小
大型推送会消耗大量资源，从而阻止或减慢服务的其他部分。 这些推送通常与典型的软件开发活动不一致，并且可能包括生成输出或 VM 映像等项目。 因此，推送一次限制为 5 GB。
大推送正常情况下有一个例外：将存储库从其他服务迁移到 Azure Repos。 此类迁移是一次性推送的，我们不打算阻止导入，即使对于大型存储库也是如此。 如果存储库超过 5 GB，则必须使用 Web 而不是命令行导入存储库 。
LFS 对象的推送大小
Git LFS 不计入 5 GB 存储库限制。 5 GB 的限制仅适用于实际存储库中的文件，而不适用于使用 LFS 存储的 blob。 如果由于 5 GB 限制而遇到推送失败的情况，请确保您 .gitattributes 的文件包含要使用 LFS 跟踪的文件的扩展名。 确保在暂存要跟踪的大文件之前保存并暂存此文件。
路径长度
Azure Repos 强制实施推送策略，该策略通过拒绝引入过长路径的推送来限制 Git 存储库中的路径长度。 与 Maximum path length （最大路径长度） 策略不同，您无法禁用或覆盖它，因为它会强制执行我们平台支持的最大值。
强制实施以下限制：
- 总路径长度：32,766 个字符
- 路径组件长度（文件夹或文件名）：4,096 个字符
此策略仅影响推送中新引入的路径。 如果您更改了现有文件，则它不适用，但如果您创建新文件、重命名或移动现有文件，则它适用。
如果推送的任何提交引入的路径超过这些限制，则推送将被拒绝，并显示以下错误消息之一：
VS403729: The push was rejected because commit '6fbe8dc700fdb33ef512e2b9e35436faf555de76' contains a path, which exceeds the maximum length of 32766 characters.VS403729: The push was rejected because commit 'd23277abfe2d8dcbb88456da880de631994dabb4' contains a path component, which exceeds the maximum length of 4096 characters.