Git 限制

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 的存储库，可以在优化过程完成之前达到包文件的内部限制。 达到此限制时，尝试写入存储库的用户将看到以下错误消息：“已达到 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 存储库中的路径长度的推送策略。 与最大路径长度策略不同，你无法禁用或替代它，因为它强制实施平台支持的最大值。

强制实施了以下限制：

• 总路径长度：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.