À propos des fichiers volumineux sur GitHub

À propos des limites de taille sur GitHub

          GitHubtente de fournir un stockage abondant pour tous les référentiels Git, bien qu’il existe des limites strictes pour  tailles de fichiers et de référentiels et les recommandations pour les tailles de référentiel.

          

Limites de taille de fichiers

          GitHub limite la taille des fichiers autorisés dans les référentiels. Si vous tentez d’ajouter ou de mettre à jour un fichier supérieur 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, voir [Supprimer des fichiers de l'historique d'un référentiel](#removing-files-from-a-repositorys-history).

          Par défaut, GitHub Enterprise Serverbloque les fichiers supérieurs à .100 Mio 
          Toutefois, un administrateur de site peut configurer une limite différente pour votre instance GitHub Enterprise Server. Pour plus d’informations, consultez [AUTOTITLE](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-repository-management-policies-in-your-enterprise).

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

Si vous devez distribuer des fichiers volumineux dans votre référentiel, vous pouvez créer des votre instance GitHub Enterprise Server versions au lieu de suivre les fichiers. Pour plus d'informations, voir Distribuer des 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.

Recommandations sur les tailles 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.

Vous pouvez éviter que votre dépôt ait un impact sur votre 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 de dépôts dans le dépôt github/git-sizer.

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

Suppression d’un fichier ajouté dans le commit non poussé le plus récent

Si le fichier a été ajouté avec votre validation la plus récente et que vous n'avez pas encore poussé vers votre instance GitHub Enterprise Server, 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 vos validations vers votre instance GitHub Enterprise Server:

   $ 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 les fichiers de l’historique du référentiel, nous vous recommandons la commande git filter-repo. Pour plus d'informations, voir Suppression de données sensibles dans un dépôt.

Si vous ne souhaitez pas installer d’outil supplémentaire, vous pouvez également utiliser un rebase interactif pour supprimer les commits problématiques. Pour ce faire :

• Vous devez savoir quel(s) commit(s) a(ont) ajouté ou modifié le fichier en question.
• Le ou les commits ne doivent faire partie que d’une seule branche.
• La branche à laquelle appartiennent les commits ne doit pas avoir fait l’objet de fusions depuis l’application du ou des commit(s).

Pour plus d'informations sur les rebases interactives, voir Utilisation du rebasage Git en ligne de commande. Si vous n’êtes pas sûr(e) de remplir les conditions nécessaires pour effectuer une correction avec un rebase interactif, vous devez utiliser git filter-repo.

Distribution de fichiers binaires volumineux

Si vous devez distribuer des fichiers volumineux dans votre référentiel, vous pouvez créer des versions sur votre instance GitHub Enterprise Server. Les versions vous permettent de regrouper des logiciels, des notes de publication et des liens vers des fichiers binaires pour l’usage d’autres personnes. Pour plus d'informations, visitez le site À propos des versions.