Limites Git

Azure DevOps Services

Nous imposons des limites de ressources aux dépôts Git dans Azure Repos afin de garantir la fiabilité et la disponibilité pour tous les clients. En gardant la taille des données et le nombre de push raisonnables, vous pouvez vous attendre à une meilleure expérience globale avec Git.

Git participe à la limitation de débit avec le reste d’Azure DevOps Services. De plus, nous imposons des limites sur la taille totale des dépôts, des envois et de la longueur des chemins d’accès aux fichiers et aux répertoires.

Taille du référentiel

La taille des référentiels ne doit pas dépasser 250 Go. Pour récupérer la taille de votre dépôt, exécutez git count-objects -vH dans une invite de commande et recherchez l’entrée appelée « 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

Nous vous recommandons de maintenir votre référentiel en dessous de 10 Go pour des performances optimales. Si votre dépôt dépasse cette taille, envisagez d’utiliser Git-LFS, Scalar ou Azure Artifacts pour gérer vos artefacts de développement.

Azure Repos réduit en permanence la taille globale et augmente l’efficacité des dépôts Git en consolidant les fichiers similaires dans des packs. Pour les dépôts approchant les 250 Go, la limite interne des fichiers de pack peut être atteinte avant la fin du processus d’optimisation. Lorsque cette limite est atteinte, les utilisateurs qui tentent d’écrire dans le référentiel voient le message d’erreur suivant : « La limite de fichiers Git pack a été atteinte, les opérations d’écriture sont temporairement indisponibles pendant la mise à jour du référentiel ». Les opérations d’écriture sont restaurées immédiatement après la fin de la tâche d’optimisation.

La taille des fichiers ne doit pas dépasser 100 Mo. Cette limite permet de garantir des performances et une fiabilité optimales du référentiel Git. Les fichiers volumineux peuvent ralentir considérablement les opérations du dépôt, telles que le clonage, l’extraction et l’envoi de modifications. Si vous avez besoin de stocker des fichiers volumineux, envisagez d’utiliser Git LFS (Large File Storage), qui est conçu pour gérer efficacement les fichiers volumineux en les stockant en dehors du référentiel principal et en ne conservant les références à ceux-ci que dans le référentiel. Cette approche permet de maintenir les performances et la facilité de gestion de votre référentiel Git.

Taille de poussée

Les envois volumineux consomment des ressources importantes, bloquant ou ralentissant d’autres parties du service. Souvent, ces notifications push ne s’alignent pas sur les activités de développement logiciel typiques et peuvent inclure des éléments tels que des sorties de build ou des images de machine virtuelle. Par conséquent, les notifications push sont limitées à 5 Go à la fois.

Il existe une exception où les envois volumineux sont normaux : la migration d’un dépôt d’un autre service vers Azure Repos. De telles migrations se font en une seule fois, et nous n’avons pas l’intention de bloquer les importations, même pour les grands dépôts. Si la taille du référentiel dépasse 5 Go, vous devez utiliser le Web pour importer le référentiel au lieu de la ligne de commande.

Taille d’envoi pour les objets LFS

Git LFS n’est pas pris en compte dans la limite de 5 Go du dépôt. La limite de 5 Go s’applique uniquement aux fichiers du référentiel réel, et non aux objets blob stockés avec LFS. Si vous rencontrez des échecs en raison de la limite de 5 Go, assurez-vous que votre .gitattributes fichier inclut les extensions des fichiers que vous avez l’intention de suivre avec LFS. Assurez-vous que ce fichier est enregistré et préparé avant de regrouper les fichiers volumineux à suivre.

Longueur des chemins d'accès

Azure Repos applique une politique Push qui limite la longueur des chemins d’accès dans un référentiel Git en rejetant les envois qui introduisent des chemins d’accès trop longs. Contrairement à la politique de longueur de chemin maximale, vous ne pouvez pas la désactiver ou la remplacer, car elle applique les valeurs maximales prises en charge par notre plateforme.

Les limites suivantes sont appliquées :

• Longueur totale du chemin d’accès : 32 766 caractères
• Longueur du composant de chemin d’accès (nom de dossier ou de fichier) : 4 096 caractères

Cette politique n’affecte que les chemins nouvellement introduits dans un push. Elle ne s’applique pas si vous modifiez un fichier existant, mais elle s’applique si vous créez un nouveau fichier, renommez ou déplacez un fichier existant.

Si des validations poussées introduisent des chemins d’accès qui dépassent ces limites, la transmission est rejetée avec l’un des messages d’erreur suivants :

• 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.