我们在 Azure Repos 中对 Git 存储库施加了一些资源限制。
我们的目标是确保所有客户的可靠性和可用性。
此外，通过将数据量和推送数量保持合理，可以期望获得更好的 Git 整体体验。
Git 与Azure DevOps的其余部分一起参与
速率限制
。
此外，我们对存储库和推送的总大小施加限制。
存储库大小
存储库不应大于 250GB。
若要检索存储库的大小，请在命令提示符下执行“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
建议将存储库保持在 10GB 以下，以实现最佳操作。
如果存储库超出此大小，请考虑使用 Git-LFS、标量或Azure Artifacts重构开发项目。
Azure DevOps通过将类似的文件合并到包中来持续减少整体大小，并提高 Git 存储库的效率。
对于接近 250 GB 的存储库，可以在优化过程完成之前达到包文件的内部限制。
尝试写入存储库的任何用户都将看到以下错误消息：“已达到 Git pack 文件限制，在更新存储库时，写入操作暂时不可用。作业完成后，将立即还原写入操作。
非常大的推送会占用大量资源，阻止或减慢服务的其他部分。
此类推送通常不会映射到正常的软件开发活动。
例如，有人无意中签入了生成输出或 VM 映像。
出于这些原因和更多原因，推送一次限制为 5GB。
有一个例外，大型推送是正常的。
将存储库从另一个服务迁移到Azure Repos时，它将作为单个推送传入。
我们不想阻止导入，甚至阻止非常大的存储库。
如果存储库超过 5GB，则必须使用 Web 导入存储库 ，而不是命令行。
LFS 对象的推送大小
Git LFS 不计入 5GB 存储库限制。 5GB 限制仅适用于实际存储库中的文件，而不适用于作为 LFS 的一部分存储的 Blob。 如果在 5GB 限制上推送失败，请验证 .gitattributes 文件是否包含你希望使用 LFS 跟踪的文件的扩展名，并且此文件已保存并暂存，然后暂存要跟踪的大型文件。
