Dernière mise à jour : 2026-06-29

Taille de clonage d'un dépôt Git

La taille de clonage d'un dépôt Git est la somme de deux composantes : l'arbre de travail (les fichiers à HEAD) et le packfile d'historique (tous les objets Git compressés). Cette estimation est utile pour dimensionner la bande passante lors d'un clonage, anticiper la capacité de stockage d'un miroir ou planifier une migration vers un autre hébergeur.

Le modèle de calcul

Le packfile d'historique résulte de l'accumulation de deltas compressés sur l'ensemble des commits. Le modèle utilisé ici est :

où $N$ est le nombre de commits, $C$ est la modification moyenne par commit avant compression (en octets), $r$ est le taux de compression du pack (fraction conservée après encodage delta et zlib), $W$ est la taille de l'arbre de travail, $H$ est la taille estimée de l'historique et $T$ est la taille totale du clone.

Exemple chiffré. Un dépôt de 100 Mo d'arbre de travail, 2 000 commits, 30 ko de modification moyenne et un taux de compression de 30 % :

Pour obtenir la taille réelle sur disque, exécutez git count-objects -vH dans le dépôt.

Comprendre les deux composantes

Arbre de travail. Il correspond aux fichiers tels qu'ils existent à HEAD, sans aucun objet Git. La commande du -sh . --exclude=.git donne cette valeur directement.

Packfile d'historique. Git ne stocke pas chaque version complète d'un fichier : il calcule des deltas entre versions successives et les compresse en blocs appelés packfiles. Plus un dépôt est ancien et actif, plus l'historique pesant est susceptible de dépasser l'instantané courant.

Le taux de compression du pack

Le paramètre $r$ traduit l'efficacité de la compression delta + zlib de Git. Il varie selon la nature des fichiers :

Une valeur de 30 % signifie que Git conserve 30 % des données delta brutes après compression ; les 70 % restants sont éliminés. Les actifs binaires ne bénéficient pas de la compression zlib, d'où des valeurs proches de 100 %.

Réduire la taille de clonage

Clone superficiel. git clone --depth N ne rapatrie que les $N$ derniers commits. Pour un dépôt de 10 000 commits, --depth 1 réduit le transfert à l'essentiel de l'arbre de travail. La réduction peut dépasser 90 % pour les anciens dépôts. Un clone superficiel peut être approfondi à tout moment avec git fetch --unshallow.

Nettoyage de l'historique. La commande git gc --aggressive ou l'outil git filter-repo permettent de supprimer définitivement des fichiers volumineux de l'historique. Cette opération modifie l'historique et nécessite une coordination avec tous les contributeurs.

Git LFS. Les actifs binaires volumineux (images haute résolution, modèles 3D, ensembles de données) ont davantage leur place dans Git Large File Storage (LFS), qui externalise ces objets du dépôt principal et ne stocke dans l'historique Git que des pointeurs légers.