Git: Passare ad un branch esistente

Per passare a un branch esistente si utilizza il comando tradizionale:
git checkout <branch>
Ad esempio, per spostarsi sul branch Test:
git checkout Test

L’operazione sposta il puntatore HEAD affinché punti al branch Test attivo: da quel momento, eventuali commit modificheranno il branch Test.

FIG 1 - git checkout

Effetti del cambio di branch

• HEAD punta al branch attivo
  Dopo git checkout test, HEAD non punta direttamente a un commit ma al riferimento simbolico del branch Test (es. HEAD -> Test). Il commit successivo aggiornerà il puntatore Test al nuovo commit.
• Modifiche alla working directory
  Al cambio di branch Git aggiorna i file nella working directory per riflettere lo snapshot dell’ultimo commit del branch di destinazione. Se le variazioni locali impediscono un passaggio netto (ad es. file modificati che verrebbero sovrascritti), Git impedisce lo switch e segnala il conflitto.
• Creazione di nuovi commit sul branch attivo
  Dopo il checkout, un commit (ad esempio git commit -a -m 'Modifica readme') avanzerà esclusivamente il puntatore del branch attivo, lasciando gli altri branch invariati. Di conseguenza, è possibile creare storie divergenti in modo isolato su differenti branch (FIG 2).

FIG 2 - Commit su Branch Test

Esempio di flusso operativo

Creazione branch (senza switch):
git branch Test

Switch al branch Test:
git checkout Test

Modifica e commit su Test:
vim readme.txt
git commit -a -m "Modifica readme"

FIG 3 - Commit su nuovo branch

Ritorno a master:
git checkout master

FIG 4 - Cambio Branch. HEAD su master

Questo riporta HEAD su master e ripristina i file alla versione indicata da master.

Divergenza della cronologia e visualizzazione

Quando si effettua lavoro parallelo su due branch differenti (ad esempio Test e master), la cronologia si diverge; successivamente le due linee potranno essere unite tramite merge o rebase. Per ispezionare la storia completa e visualizzare i punti di divergenza è utile il comando:

git log --oneline --decorate --graph --all

FIG 5 - git log

Note operative e avvisi importanti

git log non mostra sempre tutti i branch: per default git log visualizza la storia a partire dal commit riferito dal branch attualmente selezionato. Per vedere la storia di un branch specifico usare git log <branch>; per mostrare tutti i branch usare --all.

Cambiare branch modifica i file sul disco: switching ripristina la working directory allo snapshot dell’ultimo commit del branch scelto. Se Git non è in grado di effettuare queste modifiche senza perdita di dati locali, il comando verrà rifiutato.

Comportamento con modifiche non committate:

• Se si hanno modifiche locali non committate che non confliggono con i contenuti del branch di destinazione, Git generalmente permette lo switch mantenendo le modifiche.
• Se ci sono conflitti, Git bloccherà lo switch: in tal caso è necessario committare, stashare (git stash) o ripristinare (git restore) le modifiche prima di procedere.

Operazione atomica di creare+switch: è possibile creare un nuovo branch e passare a esso con un solo comando: 

git checkout -b <newbranch>

oppure, nelle versioni moderne di Git (≥ 2.23), usando git switch:

git switch -c <newbranch>

git switch (comandi raccomandati nelle versioni moderne)

A partire da Git 2.23 è consigliato usare git switch per le operazioni di cambio branch (più leggibile e focalizzato rispetto al multitool git checkout):

• Passare a un branch esistente:
  git switch Test
• Creare un nuovo branch e passare a esso:
  git switch -c new-branch
  oppure
  git switch --create new-branch
• Tornare al branch precedentemente attivo:
  git switch -

git switch separa chiaramente le semantiche di “cambio branch” da quelle di “ripristino file” che git checkout tradizionalmente confliggeva.

Best practice

• Non lavorare su main/master direttamente — usare feature branch (feature/…), bugfix branch (bugfix/…) o hotfix branch (hotfix/…) per isolare il lavoro.
• Eseguire commit atomici e frequenti: commit logici e piccoli rendono il merge e il debug più semplici.
• Sincronizzare spesso con il remoto (git fetch + git merge/rebase) prima di iniziare un lavoro esteso, per ridurre la probabilità di conflitti.
• Usare git switch quando possibile per migliorare chiarezza e sicurezza delle operazioni.
• Usare git stash per mettere temporaneamente da parte modifiche non ancora pronte se è necessario effettuare uno switch immediato.
• Visualizzare la storia con grafo (git log --oneline --decorate --graph --all) per avere un quadro completo delle divergenze e dei punti di merge.

Sintesi rapida dei comandi

Operazione	Comando
Creare un branch senza switch	git branch Test
Creare e switchare (una riga)	git checkout -b Test / git switch -c Test
Switchare su branch esistente	git checkout Test / git switch Test
Tornare all'ultimo branch	git checkout - / git switch -
Visualizzare grafo completo	git log --oneline --decorate --graph --all
Mettere da parte modifiche non committate	git stash push -m "work-in-progress"
Ripristinare stash	git stash pop

Git: Creazione di un Nuovo Branch

Quando si crea un nuovo branch in Git, in realtà non vengono duplicati file o directory, né viene generata una nuova copia del progetto.

Git si limita semplicemente a creare un nuovo puntatore (reference) a un commit esistente — un’operazione estremamente leggera e immediata.

1. Creazione di un Nuovo Branch

Per creare un nuovo branch denominato test, è sufficiente eseguire:
git branch Test
Questo comando crea un nuovo puntatore al commit corrente, ma non cambia il branch attivo.

In altre parole, il branch test viene creato, ma Git rimane ancora posizionato su master (o qualunque branch fosse attivo).

FIG 1 - Branch Test

Entrambi i branch, master e testing, puntano inizialmente allo stesso commit (40fb977).

Solo in seguito, quando si inizierà a lavorare su testing (con git switch Test o git checkout Test), i due percorsi inizieranno a divergere.

2. Il Ruolo di HEAD in Git

Per determinare su quale branch si stia lavorando, Git utilizza un puntatore speciale chiamato HEAD.

In Git, HEAD è un riferimento simbolico che punta al branch corrente.

Non va confuso con il concetto di HEAD in altri VCS (come Subversion o CVS), dove rappresenta una revisione remota.

Nel nostro esempio, dopo il comando git branch test, il puntatore HEAD rimane collegato a master (FIG 1).

3. Verifica dei Branch e del Puntatore HEAD

Per visualizzare la posizione dei vari branch rispetto ai commit, è possibile utilizzare il comando:

git log --oneline --decorate

FIG 2 - git log

In questo caso, sia master che Test puntano al commit 5e1955b.

Il simbolo HEAD -> master indica che il branch attualmente attivo è master.

4. Comprendere la Leggerezza del Branching in Git

Una delle caratteristiche più potenti di Git è la leggerezza dei branch:

• Ogni branch è semplicemente un file di testo di pochi byte che contiene l’hash del commit di riferimento.
• Creare, eliminare o spostare un branch è quindi un’operazione quasi istantanea.
• Non viene copiato alcun file, e la struttura fisica del progetto rimane invariata.

Questo approccio consente di:

• creare rapidamente branch tematici (feature branches),
• sperimentare nuove soluzioni senza rischiare di compromettere la linea principale di sviluppo,
• integrare e fondere modifiche tramite merge o rebase in modo efficiente.

5. Best Practice

• Usare nomi descrittivi per i branch, come feature/login-page o bugfix/api-timeout.
• Creare branch specifici per funzionalità o bug, per mantenere il codice principale stabile.
• Evitare di lavorare direttamente su master/main, specialmente nei progetti collaborativi.
• Verificare frequentemente la posizione di HEAD con git status o git branch --show-current.
• Eliminare i branch non più necessari con git branch -d <nome> per mantenere pulito il repository.