Partager via

Limites Git

  • Article

Azure DevOps Services

Nous imposons des limites de ressources sur les référentiels Git dans Azure Repos afin de garantir la fiabilité et la disponibilité pour tous les clients. En maintenant des tailles de données et un nombre de pushes raisonnables, vous pouvez vous attendre à une meilleure expérience globale avec Git.

Git participe au rate limiting avec le reste des services Azure DevOps. De plus, nous imposons des limites sur la taille totale des référentiels, les pushes, et la longueur des chemins de fichiers et de répertoires.

Taille des dépôts

Les référentiels ne doivent pas dépasser 250 Go. Pour récupérer la taille de votre référentiel, 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 recommandons de garder votre référentiel en dessous de 10 Go pour des performances optimales. Si votre référentiel 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 continuellement la taille globale et augmente l’efficacité des référentiels Git en consolidant des fichiers similaires dans des packs. Pour les référentiels proches de 250 Go, la limite interne des fichiers pack peut être atteinte avant la fin du processus d’optimisation. Lorsque cette limite est atteinte, les utilisateurs tentant d’écrire dans le référentiel voient le message d’erreur suivant : « La limite de fichiers pack Git 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 rétablies immédiatement après la fin de la tâche d’optimisation.

Les fichiers ne doivent pas dépasser 100 Mo. Cette limite aide à garantir des performances et une fiabilité optimales du référentiel Git. Les gros fichiers peuvent considérablement ralentir les opérations du référentiel, telles que le clonage, la récupération et le push des modifications. Si vous avez besoin de stocker de gros fichiers, envisagez d’utiliser Git LFS (Large File Storage), qui est conçu pour gérer les gros fichiers de manière efficace en les stockant en dehors du référentiel principal et en ne conservant que des références à ces fichiers dans le référentiel. Cette approche aide à maintenir les performances et la gestion de votre référentiel Git.

Taille d’envoi

Les gros pushes consomment des ressources importantes, bloquant ou ralentissant d’autres parties du service. Ces pushes ne correspondent souvent pas aux activités typiques de développement logiciel et peuvent inclure des éléments comme des sorties de build ou des images de machines virtuelles. Par conséquent, les pushes sont limités à 5 Go à la fois.

Il y a une exception où les gros pushes sont normaux : la migration d’un référentiel depuis un autre service vers Azure Repos. Ces migrations se font en un seul push, et nous n’avons pas l’intention de bloquer les importations, même pour les gros référentiels. Si le 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 ne compte pas dans la limite de 5 Go du référentiel. La limite de 5 Go s’applique uniquement aux fichiers dans le référentiel proprement dit, et non aux blobs stockés avec LFS. Si vous rencontrez des échecs de push en raison de la limite de 5 Go, assurez-vous que votre fichier .gitattributes inclut les extensions des fichiers que vous souhaitez suivre avec LFS. Assurez-vous que ce fichier est enregistré et mis en scène avant de mettre en scène les gros fichiers à suivre.

Longueur des chemins d'accès

Azure Repos applique une politique de push qui limite la longueur des chemins dans un référentiel Git en rejetant les pushes qui introduisent des chemins excessivement longs. Contrairement à la politique de longueur maximale des chemins, vous ne pouvez ni la désactiver ni la contourner, car elle impose les valeurs maximales supportées par notre plateforme.

Les limites suivantes sont appliquées :

  • Longueur totale du chemin : 32 766 caractères.
  • Longueur des composants de chemin (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 commits étant poussés introduisent des chemins qui dépassent ces limites, le push est rejeté 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.