Principe de stockage des objets

Git conserve chaque élément (commit, arbre, blob) sous forme d'objet compressé avec zlib. La taille brute d’un objet dépend donc de la redondance du contenu : plus le texte ou le binaire présente de motifs répétitifs, plus la compression réduit le volume stocké. En l’absence de packfiles, chaque objet reste un fichier individuel dans .git/objects, typiquement de l’ordre de 4 Ko après compression.

Mesures expérimentales

Un dépôt vierge occupe 64 828 bytes (64 KB) : il s’agit uniquement de la structure interne de Git. Après création de 250 fichiers contenant la chaîne « foo », le répertoire .git passe à 112 468 bytes, soit une augmentation de 47 640 bytes (47 KB) pour le premier commit.

Un changement de 3 bytes dans un fichier d’un répertoire de 50 fichiers ajoute 17 145 bytes (17 KB) à .git. Le même changement dans un dépôt à fichier unique ne génère que 8 709 bytes (8 KB). Ainsi, la surcharge initiale dépend fortement du nombre d’objets arbre créés.

L’ajout d’un fichier binaire de 583 840 bytes entraîne une croissance de 297 873 bytes (≈300 KB) : la compression supprime près de la moitié du volume brut. Un fichier texte de 16 415 223 bytes augmente .git de 1 622 188 bytes (≈1,6 MB), soit environ 10 % du fichier source, ce qui montre l’efficacité de la compression sur du texte.

git init
for d in {1..5}; do mkdir $d; for f in {1..50}; do echo foo > $d/$f; done; done
git add .
git commit -m 'initial commit'
du -sb .git

Analyse de la compression et des packfiles

Les résultats confirment que les objets « loose » sont déjà compressés, mais Git peut encore réduire la taille en créant des packfiles. Un packfile regroupe plusieurs objets et élimine les redondances inter‑objets, ce qui diminue la proportion d’en‑tête de chaque objet (les 4 KB observés). Dans les tests, la part occupée par les métadonnées représente une fraction importante pour les petits changements, expliquant les 8 KB à 17 KB pour seulement quelques octets modifiés.

Pour les gros fichiers, la compression atteint 90 % de réduction, comme le montre le binaire de 580 KB qui ne consomme que 300 KB. Le texte de 16 MB, malgré sa nature hautement compressible, reste à 10 % du volume initial, ce qui indique que la plupart des motifs sont déjà exploités par zlib.

Limites et considérations pratiques

Les mesures sont réalisées sans packfiles; en production, Git crée automatiquement des packs lors de git gc ou de pushes, ce qui peut modifier les ratios observés. De plus, la taille des objets dépend du type de données : les fichiers déjà compressés (vidéos, archives) gagnent peu de place, alors que le texte source bénéficie d’une forte réduction.

Enfin, le nombre d’objets créés par chaque commit (un commit, un ou plusieurs arbres, un blob par fichier modifié) impose un coût fixe d’environ 4 KB par objet. Cette surcharge devient négligeable lorsque le volume de données ajouté dépasse plusieurs centaines de kilooctets, mais elle reste perceptible pour des micro‑commits de quelques octets.