Skip to main content

À propos des fichiers volumineux sur GitHub

GitHub Enterprise Cloud limite la taille des fichiers que vous pouvez suivre dans les référentiels Git ordinaires. Découvrez comment suivre ou supprimer les fichiers qui dépassent la limite.

Platform navigation

À propos des limites de taille sur GitHub Enterprise Cloud

Si GitHub Enterprise Cloud tente de fournir un stockage abondant pour tous les dépôts Git, il existe des limites strictes concernant les tailles de fichiers et de dépôts. Pour garantir les performances et la fiabilité de nos utilisateurs, nous surveillons activement les signaux de l’intégrité globale du dépôt. L’intégrité du dépôt dépend de différents facteurs d’interaction, dont la taille, la fréquence de commit, le contenu et la structure.

Limites de taille de fichiers

GitHub Enterprise Cloud limite la taille des fichiers autorisés dans les dépôts. Si vous tentez d’ajouter ou de mettre à jour un fichier d’une taille supérieure à 50 Mio, vous recevrez un avertissement de Git. Les modifications seront toujours envoyées (push) à votre dépôt, mais vous pouvez envisager de supprimer la validation pour réduire l’impact sur les performances. Pour plus d’informations, consultez « Suppression de fichiers de l’historique d’un dépôt ».

Remarque : si vous ajoutez un fichier à un dépôt via un navigateur, la taille du fichier ne peut pas être supérieure à 25 Mio. Pour plus d’informations, consultez « Ajout d’un fichier à un référentiel ».

GitHub Enterprise Cloud bloque les fichiers de blocs dont la taille est supérieure à 100 Mio.

Pour suivre les fichiers au-delà de cette limite, vous devez utiliser Stockage Fichiers volumineux Git (Git LFS). Pour plus d’informations, consultez « À propos du stockage de fichiers Git volumineux ».

Si vous devez distribuer des fichiers volumineux à l’intérieur de votre référentiel, vous pouvez créer des mises en production sur GitHub.com au lieu de suivre les fichiers. Pour plus d’informations, consultez « Distribution de fichiers binaires volumineux ».

Git n’est pas conçu pour gérer des fichiers SQL volumineux. Pour partager des bases de données volumineuses avec d’autres développeurs, nous vous recommandons d’utiliser un service de partage de fichiers.

Limites de taille de dépôt

Nous conseillons de limiter la taille des dépôts petits, idéalement à moins de 1 Go, une taille inférieure à 5 Go étant vivement recommandée. Les dépôts de plus petite taille sont plus rapides à cloner et plus faciles à utiliser et à gérer. Si votre dépôt a une incidence excessive sur notre infrastructure, il se peut que vous receviez un e-mail de Support GitHub vous invitant à prendre des mesures correctives. Nous essayons d’être flexibles, en particulier avec les projets volumineux comptant de nombreux collaborateurs, et œuvrons avec vous à trouver une résolution chaque fois que c’est possible. Vous pouvez éviter que votre dépôt ait une incidence sur notre infrastructure, en gérant efficacement la taille et l’intégrité globale de votre dépôt. Vous trouverez des conseils et un outil pour l’analyse du dépôt dans le dépôt github/git-sizer.

Des dépendances externes peuvent avoir pour effet que les dépôts Git deviennent très volumineux. Pour éviter de remplir un dépôt de dépendances externes, nous vous recommandons d’utiliser un gestionnaire de package. Les gestionnaires de packages populaires pour les langages courants sont Bundler, le Gestionnaire de package de Node et Maven. Ces gestionnaires de package prenant en charge l’utilisation directe de dépôts Git, vous n’avez pas besoin de sources prépackagées.

Git n’est pas conçu pour servir d’outil de sauvegarde. Toutefois, il existe de nombreuses solutions spécifiquement conçues pour effectuer des sauvegardes, telles que Arq, Carbonite et CrashPlan.

Suppression de fichiers de l’historique d’un dépôt

Avertissement : ces procédures suppriment définitivement les fichiers du référentiel sur votre ordinateur et de GitHub.com. Si le fichier est important, effectuez une copie de sauvegarde locale dans un répertoire en dehors du dépôt.

Suppression d’un fichier ajouté dans la validation non envoyée (push) la plus récente

Si le fichier a été ajouté avec votre validation la plus récente, et que vous n’avez pas effectué d’envoi (push) à GitHub.com, vous pouvez supprimer le fichier et modifier la validation :

  1. Ouvrez TerminalTerminalGit Bash.

  2. Remplacez le répertoire de travail actuel par votre dépôt local.

  3. Pour supprimer le fichier, entrez git rm --cached :

    $ git rm --cached GIANT_FILE
    # Stage our giant file for removal, but leave it on disk
    
  4. Validez cette modification à l’aide de --amend -CHEAD :

    $ git commit --amend -CHEAD
    # Amend the previous commit with your change
    # Simply making a new commit won't work, as you need
    # to remove the file from the unpushed history as well
    
  5. Envoyez (push) vos validations à GitHub.com :

    $ git push
    # Push our rewritten, smaller commit
    

Suppression d’un fichier ajouté dans une validation antérieure

Si vous avez ajouté un fichier dans une validation antérieure, vous devez le supprimer de l’historique du dépôt. Pour supprimer des fichiers de l’historique du dépôt, vous pouvez vous servir de l’outil BFG Repo-Cleaner ou utiliser la commande git filter-repo. Pour plus d’informations, consultez « Suppression de données sensibles dans un dépôt ».

Distribution de fichiers binaires volumineux

Si vous devez distribuer des fichiers volumineux à l’intérieur de votre référentiel, vous pouvez créer des mises en production sur GitHub.com. Les mises en production vous permettent d’empaqueter des logiciels, des notes de publication et des liens vers des fichiers binaires à l’usage d’autres personnes. Pour plus d’informations, consultez À propos des versions.

Nous ne limitons pas la taille totale des fichiers binaires dans la mise en production ou la bande passante utilisée pour les livrer. Toutefois, chaque fichier doit être d’une taille inférieure à 2 Gio.