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.