Git LFS vs. Git Standard: Prestazioni per Asset di Grandi Dimensioni

Git LFS vs. Git standard diventa una domanda reale quando il tuo repository inizia a contenere asset binari di grandi dimensioni. Il codice sorgente di solito si comprime e si differenzia bene, ma video, file di design, texture di giochi, file di modelli e grandi set di dati possono rallentare le clonazioni e rendere difficile la pulizia della cronologia.

Git Large File Storage, solitamente chiamato Git LFS, mantiene il repository Git normale più leggero sostituendo i file selezionati con piccoli file puntatore e memorizzando il contenuto reale in un archivio di oggetti LFS. Questo compromesso aiuta molti team, ma non è magico. Devi ancora scegliere i file giusti, impegnare le regole di tracciamento e capire quando LFS scarica il contenuto.

Il Collo di Bottiglia delle Prestazioni di Git Standard

Git standard memorizza il contenuto impegnato nel suo database di oggetti e mantiene abbastanza cronologia per ricostruire ogni versione impegnata. Funziona magnificamente per i file di testo. Funziona male quando lo stesso file binario da 200 MB cambia molte volte.

Due problemi si manifestano rapidamente:

Formati binari come JPEG, MP4, ZIP, PSD e artefatti compilati spesso non si comprimono bene con delta.
I file cancellati rimangono nella cronologia a meno che non si riscriva la cronologia.
Le nuove clonazioni pagano per errori passati perché la cronologia Git contiene ancora quegli oggetti vecchi.
I comandi di manutenzione del repository hanno più dati da ispezionare e impacchettare.

Ad esempio, se un team impegna un grande file di design esportato ogni sprint, rimuovere il file dal ramo corrente in seguito non rimuove le sue versioni precedenti dalla cronologia. Nuovi sviluppatori e lavoratori CI potrebbero ancora scaricare dati che nessuno usa attivamente.

Introduzione a Git Large File Storage (LFS)

Git LFS è un'estensione che gestisce file selezionati al di fuori del normale database di oggetti Git. Il tuo repository mantiene un piccolo puntatore di testo. Il contenuto effettivo del file vive nell'archivio LFS fornito dal tuo host Git o da un altro server LFS.

Il Sistema di Puntatori

Un puntatore LFS assomiglia a questo:

version https://git-lfs.github.com/spec/v1
oid sha256:4c2d44962ff3c43734e56598c199589d8995a643...a89c89
size 104857600

Questo puntatore è ciò che Git normale vede. Il client Git LFS scarica il contenuto reale del file quando il checkout o un comando LFS esplicito ne ha bisogno.

Confronto delle Prestazioni: LFS vs. Git Standard

Operazione	Git Standard	Git LFS
Clonazione iniziale	Scarica la cronologia Git che include oggetti grandi impegnati	Scarica la cronologia Git con file puntatore; il contenuto LFS può essere scaricato durante il checkout a seconda della configurazione
Crescita del repository	Grandi binari possono gonfiare la cronologia `.git`	La cronologia Git rimane più piccola perché il contenuto dei file tracciati è esterno
Checkout	Utilizza oggetti già nel database Git	Potrebbe dover recuperare oggetti LFS per il commit in checkout
Lavori CI	Può sprecare tempo scaricando asset storici	Può saltare o limitare i download LFS quando le build non necessitano di asset
Pulizia	Richiede riscrittura della cronologia per rimuovere blob impegnati vecchi	Richiede ancora attenzione, ma le nuove versioni tracciate da LFS non gonfiano la cronologia Git normale

Il dettaglio importante è il comportamento del checkout. Un semplice git clone con Git LFS installato spesso scarica i file LFS necessari per il commit in checkout. Se vuoi solo puntatori, usa GIT_LFS_SKIP_SMUDGE=1 durante la clonazione e recupera i file in seguito con git lfs pull.

Quando Usare Git LFS

Git LFS è una buona scelta per file che sono grandi, binari e destinati a cambiare. Esempi comuni includono:

*.psd, *.tiff, *.blend e altri asset di design o 3D.
*.mp4, *.mov, *.wav e altri file multimediali.
Grandi file di modelli, fixture di test o set di dati richiesti dal progetto.
Binari compilati solo quando il progetto ha una chiara ragione per versionarli.

Non mettere ogni file in LFS solo perché puoi. I file di testo, il codice sorgente, i piccoli file di configurazione e i file che vuoi che Git differenzi normalmente dovrebbero rimanere in Git standard.

Controlla i limiti di archiviazione e larghezza di banda del tuo provider di hosting prima di adottare LFS. GitHub, GitLab, Bitbucket e piattaforme auto-ospitate possono differire in quote, fatturazione e comportamento di conservazione.

Implementare Git LFS

Installa il client Git LFS, quindi abilita i suoi hook per il tuo utente:

git lfs install

Traccia i pattern che vuoi che LFS gestisca:

git lfs track "*.psd"
git lfs track "assets/*.mp4"

Questi comandi creano o aggiornano .gitattributes. Impegna quel file insieme agli asset che influisce:

git add .gitattributes assets/
git commit -m "Traccia asset di design con Git LFS"
git push

Se un file grande è già stato impegnato nella cronologia Git normale, tracciarlo con LFS influisce solo sui commit futuri. Per migrare la cronologia esistente, usa uno strumento di migrazione come git lfs migrate import e coordina attentamente perché la riscrittura della cronologia cambia gli ID dei commit.

Per clonare senza scaricare immediatamente il contenuto LFS, usa:

GIT_LFS_SKIP_SMUDGE=1 git clone [email protected]:example/assets-heavy-repo.git
cd assets-heavy-repo
git lfs pull --include="assets/*.mp4"

Conclusione Pratica

Usa Git standard per codice sorgente e piccoli file di testo. Usa Git LFS per asset binari di grandi dimensioni che appartengono al repository ma non dovrebbero gonfiare la cronologia Git normale.

Per un repository di team, aggiungi regole LFS presto, impegna .gitattributes, documenta come CI gestisce i download LFS e verifica i limiti LFS del tuo host. Questo ti dà il vantaggio delle prestazioni senza sorprendere gli sviluppatori durante clonazione, checkout o build di rilascio.