Git switch vs checkout: capire la differenza

Per molto tempo, git checkout gestiva quasi tutto ciò che riguardava gli spostamenti in un repository, il cambio di branch, il ripristino dei file e l’ispezione dei commit passati. Quella flessibilità creava ambiguità. La stessa sintassi poteva significare cose diverse a seconda del contesto.

Un piccolo refuso poteva portarti a cambiare branch quando intendevi ripristinare un file. Un rapido controllo della cronologia con git checkout <commit-hash> poteva lasciarti in uno stato di HEAD staccata senza che te ne accorgessi. Il comando funzionava, ma richiedeva un’attenzione costante ai suoi molteplici comportamenti.

È qui che Git 2.23 ha introdotto git switch, un comando più specializzato per gestire le operazioni sui branch.

In questa guida ti mostrerò in cosa git switch differisce da git checkout. Vedremo anche dove ciascun comando si inserisce nei workflow moderni e daremo un’occhiata ai rispettivi ambiti.

Se Git è ancora abbastanza nuovo per te, ti consiglio di imparare le basi nel nostro corso Introduction to Git.

Che cos’è Git switch?

git switch è un comando dedicato, introdotto in Git 2.23, per gestire la navigazione e la creazione dei branch. Rende gli spostamenti tra branch più puliti, sicuri e meno soggetti a errori.

Prima della sua introduzione, gli sviluppatori usavano git checkout per cambiare branch. Il problema era che git checkout gestiva più attività non correlate: 

• Cambio di branch
• Ripristino dei file
• Ispezione dei commit

Questo rendeva il comando sovraccarico e più facile da usare in modo improprio.

Git ha risolto dividendo le responsabilità. git switch ora gestisce il cambio e la creazione dei branch, mentre git restore gestisce il ripristino dei file. Questa separazione riduce l’ambiguità e abbassa il rischio di modifiche accidentali ai file.

In pratica, git switch branch-name sposta il puntatore HEAD corrente al branch specificato. Puoi anche usare git switch -c new-branch per creare e passare a un nuovo branch.

Meccaniche di base: git switch vs checkout

Ora che hai capito perché è stato introdotto git switch, vediamo in cosa differisce effettivamente da git checkout sotto il cofano.

Gestione dei branch pensata ad hoc

Prima di Git 2.23, git checkout gestiva sia la navigazione dei branch sia il ripristino dei file. Quel design funzionava, ma mescolava due concetti fondamentalmente diversi. Muove HEAD, ripristina file e fa il checkout dei commit. A seconda di come lo usi, manipola il puntatore HEAD, l’index e la working tree.

git switch si concentra esclusivamente sullo spostamento del puntatore HEAD tra i branch. Quando esegui git switch branch-name, Git aggiorna HEAD per puntare a quel branch e adegua la directory di lavoro per allinearsi. Questo comando esiste quindi specificamente per la navigazione e la creazione dei branch. Con git switch e git restore, le responsabilità sono chiaramente divise:

• git switch sposta HEAD tra i branch.

• git restore modifica i file nella working tree o nell’index.

Per esempio, ripristinare un file richiedeva in precedenza: git checkout HEAD -- file.txt. Oggi, l’approccio consigliato è: git restore file.txt.

Qui stai ripristinando un file, non navigando tra branch. In script e documentazione di team, questa distinzione migliora la leggibilità e riduce gli errori.

Evoluzione dei comandi Git

Git 2.23 separa le responsabilità introducendo git switch per le operazioni sui branch e git restore per il ripristino dei file.

Prima di quella release, git checkout funzionava come uno strumento tuttofare. Poteva cambiare branch, ripristinare file o spostarsi su commit arbitrari. Tuttavia, questo creava confusione, soprattutto per i nuovi utenti. Dividendo il comando, Git ha ridotto l’ambiguità e reso più chiari i workflow comuni.

Comportamento della HEAD staccata

In Git, HEAD normalmente punta a un branch. Quel branch, a sua volta, punta all’ultimo commit. Quando crei un nuovo commit, Git fa avanzare il branch. Questo è il workflow standard.

Una HEAD staccata si verifica quando HEAD punta direttamente a un commit invece che a un branch. In quello stato, non sei più su un branch. Se crei un nuovo commit, Git lo crea, ma nessun nome di branch lo referenzia. A meno che tu non crei esplicitamente un branch, quei commit restano non referenziati e possono diventare difficili da ritrovare in seguito.

Quando esegui git checkout <commit-hash>, Git entra automaticamente in modalità HEAD staccata. Passa a quel commit e stacca HEAD senza richiedere conferme aggiuntive. Questo comportamento è valido, ma porta facilmente a entrare in modalità staccata in automatico.

D’altra parte, git switch richiede una menzione esplicita. Per staccare HEAD, devi usare git switch --detach <commit-hash>. Senza il flag --detach, git switch opera solo sui branch. Questo design riduce gli stati di HEAD staccata accidentali e rende i workflow sui branch più sicuri e prevedibili.

Differenze funzionali chiave tra Git switch e checkout

Ora che abbiamo coperto le differenze ad alto livello tra i due comandi, vediamo sintassi, ambito e considerazioni sulla sicurezza.

Sintassi del comando e creazione

Per creare e passare a un nuovo branch con git switch, esegui git switch -c <branch-name>. Con git checkout, il comando equivalente è git checkout -b <branch-name>.

Entrambi i comandi creano un nuovo branch e ci passano, ma la differenza sta nella chiarezza dell’intento espressa dal comando. In git switch, il flag -c indica direttamente che stai creando un branch, mentre in git checkout -b storicamente significa “branch”, ma è meno esplicito nelle intenzioni.

git switch introduce anche il flag -C: git switch -C <branch-name>. Il suo effetto è più forte di quello di -c: crea forzatamente il branch o lo reimposta se esiste già. Questo comportamento è esplicito e focalizzato sui branch. In git checkout esiste un comportamento di forza simile, ma le semantiche sono meno chiaramente separate perché il comando serve a più scopi.

Ambito delle operazioni

git switch funziona solo con i branch. Non può ripristinare file, rimuovere dallo stage le modifiche o fare il checkout di percorsi specifici da commit precedenti. In sostanza, non supporta operazioni a livello di file.

Al contrario, git checkout può operare a livello di file. Per esempio, git checkout <commit> -- <file> ripristina un file specifico da un commit passato. 

Tuttavia, la documentazione moderna di Git suggerisce di usare git restore per questo scopo. Il punto chiave è che git switch esclude deliberatamente la manipolazione dei file per mantenere un ambito ristretto e prevedibile.

Sicurezza e disambiguazione

Un problema comune con git checkout è l’ambiguità. Se un nome di branch e un nome di file sono identici, a seconda del contesto potrebbe cambiare branch o ripristinare un file. git switch evita del tutto questa ambiguità. Opera solo sui branch. Se non fornisci un nome di branch valido, Git fallisce chiaramente invece di indovinare. 

git switch fornisce anche una gestione degli errori più chiara quando le modifiche locali confliggono con il branch di destinazione. Se cambiare branch sovrascriverebbe lavoro non confermato, Git interrompe l’operazione e mostra un messaggio di errore diretto, come i seguenti: 

• Se il branch non esiste: fatal: invalid reference: feature/login

• Se le modifiche locali verrebbero sovrascritte: error: Your local changes to the following files would be overwritten by checkout

• Se il branch esiste già quando usi -c: fatal: a branch named 'feature/login' already exists

Messaggi di errore chiari come questi riducono i cambi di stato accidentali.

Esempi pratici di Git switch

Capire git switch diventa molto più semplice quando lo vedi in workflow reali. Questi esempi mostrano come si comporta nella gestione quotidiana dei branch e perché risulta più sicuro e prevedibile di git checkout.

Operazioni standard sui branch

Nello sviluppo quotidiano, ti muovi soprattutto tra branch o ne crei di nuovi.

• Per passare a un branch locale esistente, usa: git switch <branch_name>. Qui Git sposta HEAD sul branch indicato e aggiorna la tua directory di lavoro per allinearla a quel branch.

• Per creare un nuovo branch per una nuova feature chiamata “new_ui” e passarci in un passaggio, usa git switch -c feature/new-ui. Questo crea il branch dal commit corrente e sposta immediatamente HEAD su di esso.

• Se devi reimpostare o sovrascrivere un branch esistente, usa: git switch -C feature/new-ui. La -C maiuscola forza la creazione o reimposta il puntatore del branch. Rende esplicita l’intenzione distruttiva.

• Puoi anche alternare rapidamente tra gli ultimi due branch con git switch -. È molto comodo quando rivedi il codice su un branch e torni ripetutamente al tuo branch di feature.

Gestione dei branch remoti

Spesso, un branch esiste sul remoto ma non in locale. Per esempio, qualcuno esegue il push di origin/bugfix, ma tu non l’hai ancora creato in locale.

• Se esegui: git switch bugfix, Git creerà un branch locale bugfix e lo imposterà per tracciare il branch remoto origin/bugfix, assumendo che ci sia una corrispondenza chiara su origin. Questo semplifica la collaborazione perché non devi impostare manualmente il tracking upstream.

• Se vuoi impedire a Git di indovinare, usa: git switch --no-guess bugfix. Ora Git fallisce se il branch non esiste in locale. È utile in workflow più rigidi dove il tracking automatico potrebbe creare confusione.

• Se preferisci essere esplicito quando crei un branch di tracking, usa git switch -c bugfix --track origin/bugfix. Questo rende chiara la relazione di tracking direttamente nel comando.

Ispezione sperimentale dei commit

A volte vuoi solo dare un’occhiata a un commit vecchio. Magari vuoi testare una versione precedente o verificare quando è stato introdotto un bug. In quel caso, vuoi spostarti temporaneamente a quel punto della storia.

Con git switch, devi dirlo esplicitamente: git switch --detach <commit-hash>.

Il flag --detach dice a Git: sposta HEAD direttamente su questo commit, non su un branch. Ora puoi esplorare il codice, eseguire i test o compilare il progetto. Se crei nuovi commit in questo stato, non sono collegati ad alcun branch a meno che tu non ne crei uno.

Con git checkout <commit-hash>, la stessa azione avviene automaticamente senza un flag aggiuntivo. Questo rende facile entrare involontariamente in modalità staccata, mentre richiedere il flag --detach in git switch evita stati di HEAD staccata accidentali. 

Integrazione di Git switch nel workflow

Vediamo ora come integrare git switch nei tipici workflow Git.

Scelta in base allo scenario

Nei workflow di sviluppo moderni, git switch dovrebbe gestire tutto ciò che riguarda i branch. Questo include 

• Sviluppo di feature di routine
• Revisione delle pull request
• Rebase in locale
• Script CI/CD che fanno il checkout dei branch durante le build

Poiché git switch si concentra solo sulla gestione dei branch, comunica chiaramente l’intento.

git checkout ha ancora un ruolo, ma ora è più ristretto. Le automazioni legacy scritte prima di Git 2.23 spesso vi fanno affidamento. Alcune operazioni di ripristino a livello di file possono ancora usarlo, anche se in futuro git restore è il sostituto preferito.

Risoluzione dei problemi comuni

Ci sono due scenari distinti che possono creare problemi mentre usi git switch.

“Your local changes would be overwritten”

Un problema comune che compare quando provi a cambiare branch con modifiche locali presenti è “error: Your local changes would be overwritten”. Qui Git blocca l’operazione perché il cambio sovrascriverebbe lavoro non confermato. Hai due opzioni sicure per superare questo ostacolo:

1. Se vuoi conservare le modifiche per dopo, esegui git stash prima di passare al branch di destinazione. Dopo il cambio, puoi ripristinarle con git stash pop.

2. Se vuoi intenzionalmente scartare le modifiche locali, usa: git switch --discard-changes target-branch. Questa opzione dice a Git di eliminare le modifiche locali e reimpostare index e working tree per allinearli al branch di destinazione (non rimuove i file non tracciati).

Entrare accidentalmente in uno stato di HEAD staccata

Un altro scenario è entrare accidentalmente in uno stato di HEAD staccata. Se ti accorgi di non essere su un branch ma hai del lavoro che vuoi conservare, crea subito un nuovo branch: git switch -c recovery-branch. Questo collega la cronologia dei commit corrente a un branch nominato e preserva le tue modifiche.

Best practice nell’adozione di Git switch

Adottare git switch non è solo una preferenza di comando. È un piccolo aggiornamento strutturale al modo in cui i team pensano ai workflow Git. I benefici aumentano quando l’adozione è coerente tra documentazione, onboarding e automazione.

Strategie di migrazione del team

Inizia dalla documentazione interna. Se le tue guide “Getting Started” insegnano ancora git checkout per cambiare branch, aggiornale a git switch. Mantieni checkout solo dove è davvero necessario.

Anche la formazione ha un ruolo. Modern Git commands providiano messaggi di errore più chiari, soprattutto quando le modifiche locali confliggono con un cambio di branch. Incoraggia gli sviluppatori a leggere e comprendere questi messaggi invece di trattarli come errori generici. Il set di comandi più recente è più esplicito e riconoscerlo aumenta la sicurezza e riduce gli errori.

Coerenza nelle automazioni

In script shell, pipeline CI e alias Git, preferisci git switch per la navigazione tra i branch perché comunica immediatamente l’intento. Uno script che usa git switch main è più facile da interpretare di uno che si affida a git checkout, che può avere più significati. 

Se definisci alias Git, aggiornali per riflettere l’uso moderno. Per esempio, un alias per creare branch di feature dovrebbe incapsulare git switch -c, non git checkout -b.

Infine, verifica le versioni di Git negli ambienti. git switch richiede Git 2.23 o superiore. Assicurati che le macchine degli sviluppatori, i runner CI e i server di build soddisfino questo requisito prima di standardizzare sul nuovo comando. Un semplice controllo di versione evita sottili problemi di compatibilità.

Conclusioni

Se allunghi lo sguardo al quadro generale, il vero vantaggio di git switch è semplice. Rende la gestione dei branch più chiara, sicura e intenzionale. Quando esegui il comando, non c’è ambiguità su quello che sta facendo. Stai cambiando branch. Punto. E quel piccolo livello di chiarezza elimina una sorprendente quantità di attrito nello sviluppo quotidiano.

Tuttavia, git checkout non è stato deprecato; puoi ancora usarlo per ripristinare file, passare tra branch o gestire scenari più complessi. Ma per la navigazione quotidiana tra branch, Git ti incoraggia a usare git switch.

Come prossimo passo, ti consiglio il nostro corso Intermediate Git, incentrato sulla collaborazione con Git.