Ultimo aggiornamento: 2026-06-29

Dimensione di un repository git: struttura e stima

Un repository git è composto da due parti distinte: il working tree, che contiene i file nella loro versione corrente, e la directory .git, che custodisce l'intera cronologia del progetto sotto forma di oggetti compressi. La dimensione totale trasferita con git clone corrisponde alla somma di entrambe le componenti.

Struttura degli oggetti git e packfile

Git archivia ogni versione di ogni file come un oggetto immutabile identificato da un hash SHA-1. Quando un file viene modificato, git non sovrascrive la versione precedente: crea un nuovo oggetto e mantiene quello originale. In un progetto attivo con centinaia di collaboratori, il numero di oggetti cresce rapidamente.

Per ottimizzare lo spazio, git raggruppa periodicamente gli oggetti sciolti in un packfile. All'interno del packfile, gli oggetti simili vengono confrontati e conservati come differenze (delta) rispetto a un oggetto base, dopodiché l'intero archivio viene compresso con zlib. Il risultato è che la directory .git/objects può contenere dati molto più compatti rispetto alla somma grezza degli oggetti originali.

Formula di stima

Il modello euristico alla base di questo strumento è:

dove $N$ è il numero di commit, $C$ è la variazione media per commit (in byte, prima della compressione), $r$ è il rapporto di compressione del packfile, $W$ è la dimensione del working tree e $T$ è la dimensione totale del clone.

Il parametro $r$ rappresenta la frazione di dati delta che rimane dopo la codifica delta di git e la compressione zlib. Un valore di 0,30 significa che il packfile occupa il 30 % dei dati grezzi; i repository con prevalenza di codice sorgente si attestano tipicamente tra 0,20 e 0,40.

Esempio pratico

Si consideri un repository con le seguenti caratteristiche:

• Working tree: 100 MB
• Numero di commit: 2.000
• Variazione media per commit: 80 kB
• Rapporto di compressione: 30 %

La dimensione stimata della cronologia è:

La dimensione totale del clone risulta quindi:

Per repository con una cronologia più lunga o con commit che modificano file di grandi dimensioni, la componente $H$ può superare di gran lunga $W$, spiegando perché la directory .git risulta più grande del codice sorgente effettivo.

Clone superficiale e riduzione della banda

Il comando git clone --depth N scarica soltanto gli ultimi $N$ commit della cronologia, trasferendo di fatto solo lo snapshot corrente più un sottile strato di oggetti. Per un repository con 10.000 commit, un clone superficiale con --depth 1 può ridurre la banda necessaria del 90 % o più.

Questa tecnica è comune nelle pipeline di integrazione continua, dove la cronologia completa non è necessaria per compilare e testare il codice. Il clone superficiale può essere completato in un secondo momento con git fetch --unshallow, quando si ha bisogno della cronologia intera.

Limiti del modello

La stima fornita è di natura euristica e si basa su alcune semplificazioni:

• La variazione media per commit è trattata come uniforme su tutta la cronologia, mentre in realtà può variare significativamente nelle diverse fasi di un progetto.
• La compressione effettiva dipende dai tipi di file (il codice sorgente si comprime molto meglio degli asset binari o dei file già compressi come JPEG e ZIP).
• Operazioni come git gc e git repack con opzioni aggressive possono ridurre ulteriormente le dimensioni rispetto a quanto stimato.
• La profondità delle catene delta e il numero di packfile separati influenzano i tempi di accesso ma non compaiono nel modello.

Per la dimensione reale su disco, eseguire:

git count-objects -vH

Questo comando riporta separatamente il numero di oggetti sciolti e la dimensione dei packfile, fornendo una misura precisa dello spazio occupato dalla directory .git.