Cloni superficiali in Git: quando e come usarli
Usa i cloni superficiali per checkout Git rapidi in CI e lavori temporanei, e impara come approfondire o rimuovere la superficialità quando hai bisogno di più cronologia.
Cloni superficiali in Git: quando e come usarli
I cloni superficiali in Git recuperano solo una parte della cronologia dei commit. Sono utili quando un lavoro CI, un passaggio di distribuzione o un'ispezione rapida necessitano del codice corrente ma non di anni di cronologia.
Non sono la scelta predefinita migliore per ogni workstation di sviluppo. Un clone superficiale può risparmiare tempo e spazio su disco, ma limita anche i comandi basati sulla cronologia finché non recuperi più commit.
Cos'è un clone superficiale?
Un clone standard recupera abbastanza cronologia per il normale lavoro sui rami, l'ispezione della cronologia, il checkout di tag vecchi e l'indagine offline. Un clone superficiale tronca quella cronologia a una profondità che scegli.
Ad esempio, --depth 1 recupera il commit più recente per il ramo selezionato. --depth 50 recupera più cronologia recente, ma ancora non l'intera discendenza.
Vantaggi dell'uso dei cloni superficiali
Il vantaggio principale è un costo di trasferimento inferiore:
- Checkout iniziale più veloce per repository grandi.
- Minor utilizzo del disco su agenti di build di breve durata.
- Minor larghezza di banda su reti lente o a consumo.
- Meno cronologia da elaborare per Git durante il clone iniziale.
In una pipeline CI che costruisce il commit corrente e butta via l'area di lavoro, un clone superficiale è spesso un guadagno netto.
Svantaggi e limitazioni dei cloni superficiali
Il compromesso è la cronologia mancante:
git logsi ferma al confine superficiale.git blamepotrebbe non essere in grado di seguire modifiche più vecchie.- Tag o commit vecchi potrebbero non essere disponibili finché non vengono recuperati.
- Rebasing e merge possono essere più difficili se Git ha bisogno di una base di merge mancante.
- Alcuni flussi di lavoro di rilascio o audit si aspettano una cronologia completa.
Se il tuo lavoro spesso implica il debug di regressioni vecchie, la preparazione di rilasci o il backport di modifiche, inizia con un clone completo.
Come creare un clone superficiale
Usa git clone --depth:
git clone --depth <numero> <url_repository>
Ad esempio, per clonare un repository e recuperare solo gli ultimi 10 commit:
git clone --depth 10 https://github.com/esempio/repo-grande.git
Per un lavoro di build che necessita solo del ramo più recente:
git clone --depth 1 https://github.com/esempio/progetto.git
Per clonare un ramo specifico:
git clone --depth 1 -b develop https://github.com/esempio/progetto.git
Puoi anche aggiungere --single-branch quando vuoi solo la cronologia per quel ramo:
git clone --depth 1 --single-branch --branch develop https://github.com/esempio/progetto.git
Gestione dei cloni superficiali
Recuperare più cronologia (approfondire il clone)
Se hai bisogno di più cronologia dopo il clone, approfondisci il repository:
git fetch --deepen=50 origin
Questo recupera 50 commit in più oltre l'attuale confine superficiale.
Puoi anche impostare la profondità totale desiderata:
git fetch --depth=100 origin
Il punto importante: git remote set-depth non è un comando Git valido. La profondità è controllata tramite le opzioni di clone e fetch.
Recuperare i tag
I cloni superficiali potrebbero non includere tutti i tag, specialmente quelli che puntano a commit più vecchi. Recupera i tag solo se il tuo flusso di lavoro ne ha bisogno:
git fetch --tags origin
Rimuovere la superficialità di un repository
Per convertire un clone superficiale in un clone completo, recupera il resto della cronologia:
git fetch --unshallow origin
Questo comando scaricherà la cronologia rimanente dal repository remoto.
Push da un clone superficiale
Il push da un clone superficiale può funzionare quando i tuoi nuovi commit sono basati sul ramo remoto più recente che hai recuperato. È comunque una scelta poco adatta per uno sviluppo a lungo termine perché la cronologia mancante può rendere più difficili rebase, risoluzione dei conflitti e revisione.
Se incontri problemi di push o merge legati alla cronologia, recupera più cronologia o rimuovi la superficialità del clone prima di continuare.
Quando usare i cloni superficiali
Usali quando il lavoro è di breve durata e la cronologia non è importante:
- Checkout CI/CD.
- Ispezione in sola lettura.
- Ambienti di riproduzione temporanei.
- Build di documentazione.
- Repository grandi su reti lente.
Quando non usare i cloni superficiali
Evitali quando hai regolarmente bisogno di:
git log,git blameogit bisectapprofonditi.- Lavoro di rilascio che utilizza tag vecchi.
- Lavoro complesso di merge o rebase.
- Debug offline attraverso la cronologia.
- Flussi di lavoro di contribuzione che si aspettano un clone completo.
Conclusione pratica
Usa git clone --depth 1 per lavori usa e getta che necessitano solo del codice più recente. Usa un clone completo per lo sviluppo normale a meno che tu non abbia una chiara ragione per non farlo.
Se un clone superficiale inizia a intralciarti, approfondiscilo con git fetch --deepen=<numero> origin o convertiscilo con git fetch --unshallow origin. Di solito è più veloce e più sicuro che combattere errori di cronologia mancante un comando alla volta.