Limites du dépôt

Certains types de ressources du référentiel peuvent être très volumineux et nécessiter un traitement excessif sur GitHub. En raison de cela, les limites sont définies pour s’assurer que les demandes sont terminées dans un délai raisonnable. Le dépassement de la limite maximale recommandée augmente le risque d’intégrité détériorée du référentiel, ce qui inclut, mais n’est pas limité aux temps de réponse lents pour les opérations Git de base et la latence de l’interface utilisateur.

La plupart des limites ci-dessous affectent à la fois GitHub et l'API.

Taille du référentiel

Pour garantir des performances et une facilité de gestion optimales, nous vous recommandons de rester dans les limites maximales suivantes pour la structure et la taille du référentiel.

•         ** Taille du disque** : 10 Go
  

  La taille du disque fait référence à la taille du dossier .git (forme compressée du référentiel). Les grands référentiels peuvent ralentir les opérations de récupération et augmenter les temps de clonage pour les développeurs et l'intégration continue (CI). Pour gérer la taille de référentiel :

  • Utilisez Stockage Fichiers volumineux Git (Git LFS) pour les fichiers binaires.
  • Stockez des fichiers générés par programmation en dehors de Git, comme dans le stockage d’objets.

•         **Largeur du répertoire (nombre d’entrées dans un répertoire unique)**  : 3 000
  

  Les répertoires contenant de nombreux fichiers fréquemment modifiés peuvent augmenter considérablement les coûts de maintenance des référentiels et dégrader les performances des opérations Git de base. La segmentation des fichiers dans une structure de répertoire peu profonde réduira la taille de ces arborescences et entraînera une diminution des nouvelles données créées.

•         **Profondeur du répertoire** : 50
  

  Les arborescences de répertoires profonds peuvent ralentir les opérations de navigation dans l'historique.

•         **Nombre de branches** : 5 000
  

  Un grand nombre de branches peut entraîner des données inutiles dans les opérations d’extraction, ce qui entraîne des temps de transfert lents ou, dans des cas extrêmes, des performances limitées du référentiel.

Activité

Pour éviter les problèmes de limitation et de performances, nous vous recommandons de rester dans les limites opérationnelles suivantes.

•         **Taille push** : cette limite est appliquée à 2 Go.
  

•         **Taille de l'objet unique** :
  

  La limite maximale recommandée est de 1 Mo. Cela est appliqué à 100 Mo. Pour suivre des fichiers volumineux dans un référentiel Git, nous vous recommandons d’utiliser Git LFS. Consultez « À propos du stockage de fichiers Git volumineux ».

•         **Opérations de lecture Git (par exemple, extractions, clones)**  :
  

  La limite maximale recommandée est de 15 opérations par seconde par dépôt. Un grand nombre d'opérations de lecture peut entraîner un ralentissement des performances d'un référentiel. Les processus automatisés tels que l’intégration continue, les utilisateurs d’ordinateurs ou les applications tierces peuvent dégrader les performances d’un référentiel dans certains cas. Envisagez d’optimiser la stratégie de clonage de votre CI et/ou d’utiliser un serveur de cache de référentiel. Notez que les clones peu profonds imposent moins de coûts et de charges au serveur que les clones complets et peuvent donc être plus performants.

•         **Taux d’envoi (push)**  : la limite maximale recommandée est de 6 envois push par minute par référentiel.
  

Limites de texte

GitHub affiche des aperçus formatés de certains fichiers, tels que les diagrammes Markdown et Mermaid. GitHub tente toujours d’afficher ces aperçus si les fichiers sont petits (généralement inférieurs à 2 Mo), mais les fichiers plus complexes peuvent expirer et revenir au texte brut ou ne pas être affichés du tout. Ces fichiers sont toujours disponibles dans leurs formats bruts, qui sont servis par HOSTNAME/user/repo/raw, par exemple https://HOSTNAME/user/repo/raw/octocat/Spoon-Knife/main/index.html. Cliquez sur le bouton Brut pour obtenir l’URL brute d’un fichier.

Limites des pull requests

Pour réduire les retards et les problèmes de performances dans les référentiels avec une activité de demande de tirage élevée, nous vous recommandons de rester dans les limites suivantes.

•         **Requêtes d’extraction ouvertes (par rapport à la même branche)**  : 1 000
  

  La présence de nombreuses demandes de tirage ouvertes ciblant la même branche peut ralentir les vérifications de fusion ou entraîner des dépassements de délais. Si vous utilisez une file d’attente de fusion, envisagez de désactiver le paramètre « exiger que cette branche soit à jour avant la fusion ». Cela limite les vérifications de capacité de fusion aux seules demandes de tirage dans la file d'attente.

•         **Taux de fusion des demandes de tirage (pull request)**  : 1 demande de tirage fusionnée par minute
  

  Chaque fusion déclenche des vérifications de compatibilité de fusion pour toutes les pull requests ouvertes, ce qui peut causer des goulots d'étranglement au niveau des performances, en particulier dans les dépôts très sollicités. Cela peut également entraîner une situation de course à la fusion susceptible de nuire à la productivité des développeurs. Pour réduire la charge, désactivez le paramètre « exiger que cette branche soit à jour avant la fusion », lorsque vous utilisez une file d'attente de fusion.

Limites de différences

Étant donné que les différences peuvent devenir très volumineuses, nous imposons ces limites aux différences pour les validations, les demandes de tirage et les affichages de comparaison :

• Dans une demande de tirage, aucune différence totale ne peut dépasser 20 000 lignes que vous pouvez charger ou 1 Mo de données de différences brutes.
• Aucune différence de fichier unique ne peut dépasser 20 000 lignes que vous pouvez charger ou 500 Ko de données de différences brutes. Quatre cents lignes et 20 Ko sont automatiquement chargés pour un seul fichier.
• Le nombre maximal de fichiers dans un seul diff est limité à 300.
• Le nombre maximal de fichiers pouvant être affichés (tels que les images, les fichiers PDF et GeoJSON) dans une seule différence est limité à 25.

Certaines parties d’une différence limitée peuvent être affichées, mais tout ce qui dépasse la limite n’est pas affiché.

Limites des listes de validation

Les pages de comparaison des affichages et des demandes de tirage affichent une liste de validations entre les révisions base les head. Ces listes sont limitées à 250 validations. Si elles dépassent cette limite, une note indique que des validations supplémentaires sont présentes (mais qu’elles ne sont pas affichées).

Le nombre maximum de commits affichés dans l’onglet Commits est de 10 000. Utiliser d’autres outils tels que git rev-list --count mybranch pour compter et énumérer un volume important de commits lorsque cela est nécessaire.

Rebase des limites

La fusion d'une pull request avec l'option « Rebaser et fusionner » est limitée à 100 commits. Si vous avez une demande de tirage avec plus de 100 commits, vous devez créer un commit de fusion, écraser et fusionner, ou fractionner les commits en plusieurs demandes de tirage.

Limites de l’organisation et du compte

Les organisations et les comptes ne peuvent pas dépasser 100 000 dépôts. Lorsqu’un compte dépasse 50 000 référentiels, une bannière s’affiche pour signaler que la limite est presque atteinte. De plus, les administrateurs reçoivent des notifications par e-mail et le journal d’audit est mis à jour tous les 5 000 référentiels supplémentaires créés. Consultez « À propos des dépôts ».

Intégrations et GitHub Apps

Lors de la génération d’une intégration sur GitHub, stockez les données générées par les utilisateurs dans leurs propres comptes GitHub plutôt que de les centraliser dans votre compte. Les utilisateurs conservent ainsi le contrôle total de leur travail et vous évitez de dépasser les limites du référentiel.