Accelera Git: Tecniche Essenziali di Ottimizzazione delle Prestazioni

Un Git lento di solito ha una causa concreta: troppa cronologia, troppi file non tracciati, oggetti binari di grandi dimensioni, scansioni costose del filesystem o latenza di rete. Prima di incolpare Git stesso, verifica quale operazione è lenta e cosa sta cercando di leggere o scaricare.

L'ottimizzazione delle prestazioni di Git funziona meglio quando abbini la soluzione al sintomo. Un clone CI lento necessita di una risposta diversa rispetto a un lento git status in un albero di lavoro enorme.

Comprendere le Cause delle Prestazioni Lente di Git

Inizia con le cause comuni:

Una lunga cronologia con molti file e riferimenti.
File binari di grandi dimensioni committati direttamente in Git.
Output di build, cartelle di dipendenze o log lasciati non ignorati nell'albero di lavoro.
Molti rami di tracciamento remoto e tag obsoleti.
Collegamenti di rete lenti verso il remoto.
Versioni vecchie di Git prive dei miglioramenti più recenti di manutenzione e checkout sparso.

Esegui il comando lento con intenzione. Se git clone è lento, guarda la dimensione della cronologia e il trasferimento di rete. Se git status è lento, guarda la dimensione dell'albero di lavoro, i file ignorati e il comportamento del filesystem. Se git fetch è lento, guarda i riferimenti remoti, i tag e gli oggetti modificati.

Riduci il Costo di Clone e Fetch

Per CI, lavori di deployment e ispezione in sola lettura, spesso non hai bisogno dell'intera cronologia.

Usa un clone superficiale:

git clone --depth <numero> <url_repository>

Ad esempio, per clonare solo gli ultimi 10 commit:

git clone --depth 10 https://github.com/esempio/repo.git

Per lavori CI che costruiscono solo il commit corrente, --depth 1 è spesso sufficiente. Per il lavoro degli sviluppatori, un clone completo è di solito meno sorprendente perché comandi come git log approfondito, il checkout di tag vecchi e alcuni rebase necessitano di più cronologia.

Se hai già un clone superficiale e hai bisogno di più cronologia, approfondiscilo:

git fetch --deepen=50 origin

Oppure convertilo in un clone completo:

git fetch --unshallow origin

Per esigenze di dati parziali, le versioni più recenti di Git supportano anche filtri di clone parziale come --filter=blob:none, ma usali solo quando il tuo host Git e il flusso di lavoro li supportano bene:

git clone --filter=blob:none https://github.com/esempio/repo-grande.git

Tieni i File Grandi Fuori dalla Cronologia Normale di Git

I binari grandi sono uno dei modi più veloci per rendere Git lento. Immagini, video, archivi, file di design e file di modello spesso non si comprimono o differenziano bene.

Usa Git LFS per asset grandi che appartengono veramente al repository:

git lfs install
git lfs track "*.psd"
git lfs track "assets/*.mp4"
git add .gitattributes
git commit -m "Traccia asset grandi con Git LFS"

Git LFS influisce sui commit futuri dopo che le regole di tracciamento sono state impostate. Se qualcuno ha già committato file grandi nella cronologia normale di Git, rimuoverli dall'albero corrente non è sufficiente. Potresti aver bisogno di una riscrittura coordinata della cronologia con uno strumento come git lfs migrate import o git filter-repo.

Per gli artefatti di build generati, la risposta migliore di solito non è LFS. Non committarli. Aggiungili invece a .gitignore:

node_modules/
dist/
coverage/
*.log

Pulisci i Riferimenti e gli Oggetti Locali

I rami di tracciamento remoto obsoleti aggiungono confusione e possono rallentare i comandi che elencano o ispezionano i riferimenti. Potali durante il fetch:

git fetch --prune

Elimina i rami locali che sono già stati uniti e non sono più necessari:

git branch --merged
git branch -d vecchio-ramo-funzionalità

Lascia che Git esegua la manutenzione:

git maintenance run

Nei flussi di lavoro più vecchi, git gc è ancora utile:

git gc

Evita comandi di pulizia aggressivi a meno che tu non sappia perché ne hai bisogno. Ad esempio, far scadere i reflog può rendere più difficile recuperare da un reset errato.

Rendi `git status` Più Economico

git status deve ispezionare l'albero di lavoro. Se la directory del tuo progetto contiene migliaia di file generati o di dipendenze, lo stato può diventare rumoroso e lento.

Usa .gitignore per i file che Git non dovrebbe considerare. Se un file è già tracciato, .gitignore non impedirà a Git di tracciarlo; devi prima rimuoverlo dall'indice:

git rm --cached percorso/del/file-generato

Per repository molto grandi dove hai bisogno solo di una parte dell'albero, il checkout sparso può aiutare:

git sparse-checkout init --cone
git sparse-checkout set servizi/api docs

Questo mantiene solo i percorsi selezionati nel tuo albero di lavoro. È utile nei monorepo, ma il tuo team dovrebbe documentare i percorsi sparsi previsti in modo che gli sviluppatori non perdano i file di cui hanno bisogno.

Separa il Fetch dall'Integrazione

git pull recupera e poi integra le modifiche con merge o rebase, a seconda della configurazione. Quando un repository è grande o un ramo ha diverguto, è spesso più chiaro fare prima il fetch:

git fetch origin
git log --oneline HEAD..origin/main
git merge origin/main

Questo non rende il trasferimento di rete più piccolo di per sé. Ti dà il controllo prima di modificare il tuo ramo di lavoro.

Conclusione Pratica

Usa cloni superficiali per lavori di breve durata, Git LFS per asset grandi, .gitignore per file generati, potatura per riferimenti obsoleti e checkout sparso per alberi grandi dove hai bisogno solo di un sottoinsieme. Mantieni Git aggiornato, ma non usare strumenti di integrità come git fsck come soluzione per le prestazioni a meno che non sospetti una corruzione del repository.

Quando Git sembra lento, annota il comando esatto e dove va il tempo: trasferimento di rete, elaborazione degli oggetti o scansione dell'albero di lavoro. Quel singolo dettaglio di solito indica l'ottimizzazione giusta.