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、标量或 Azure Artifacts 重构开发项目。
Azure Repos通过将类似文件合并到包中来不断减小整体大小并提高 Git 存储库的效率。 对于接近 250 GB 的存储库,可以在优化过程完成之前达到包文件的内部限制。 任何尝试写入存储库的用户都会看到以下错误消息:“已达到 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 个字符
- 路径组件长度 (,即文件夹或文件名) :4096 个字符
它仅影响推送中新引入的路径。 如果更改现有文件,则不适用。 但是,如果创建新文件或重命名或移动现有文件,则它确实适用。
如果推送的某些提交引入了超出限制的路径,则会拒绝推送,并显示以下错误消息之一:
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.