Modulo 06 — Branching

Perché servono i branch

Su progetti grandi si lavora su contesti multipli in parallelo. Esempio realistico:

1. due varianti di schema colori del sito, non si sa ancora quale piacerà;
2. un bug ostinato su cui “frugare” togliendo e mettendo codice;
3. un widget di chat da presentare alla riunione, senza certezze sul futuro;
4. un collega che aggiorna l’autocomplete della ricerca;
5. un altro che prepara un redesign radicale da mostrare il mese prossimo.

I branch sono l’essenza di Git: pensali come timeline alternative del progetto. Creano contesti separati dove sperimentare o lavorare in parallelo; le modifiche su un branch non impattano gli altri (a meno che tu non le mergi).

Il branch di default: master (o main)

In Git si lavora sempre su un branch. Quello di default si chiama master, che dal punto di vista di Git non ha nulla di speciale: è un branch come gli altri.

Molte squadre lo designano come “fonte della verità” o branch ufficiale, ma è una convenzione, non una regola. Nel 2020 GitHub ha rinominato il default da master a main; il nome di default di Git resta master, anche se potrebbe cambiare.

Come funziona internamente (in breve)

• Un branch è semplicemente un puntatore all’ultimo commit di quella linea di lavoro.
• Ogni commit punta al proprio commit genitore (parent), formando la catena della history.
• Quando crei un branch, nasce solo un nuovo puntatore; quando committi su quel branch, il suo puntatore avanza.

La history è una catena: ogni commit punta al proprio genitore, fino al primo commit che non ne ha.

HEAD è il puntatore alla “posizione corrente” nel repository: normalmente punta a un branch reference (es. master), che a sua volta punta all’ultimo commit. Vedrai nel log annotazioni tipo (HEAD -> master).

HEAD punta al riferimento del branch, il riferimento punta all’ultimo commit: la posizione corrente è indiretta.

Quando committi: il branch reference si aggiorna al nuovo commit, HEAD resta dov’è (punta al branch). Quando cambi branch: HEAD passa a puntare al nuovo branch reference.

Con ogni nuovo commit il puntatore del branch avanza in avanti; HEAD resta fermo perché punta al branch.

Comandi per i branch

Vedere i branch

git branch      # elenca i branch; l'asterisco indica quello corrente
git branch -v   # con hash e messaggio dell'ultimo commit di ciascuno

Creare un branch

git branch bugfix

Crea il branch a partire dall’HEAD corrente, ma non ti porta lì: resti sul branch attuale.

Passare a un branch

git switch bugfix

Ora HEAD punta al branch bugfix: i nuovi commit esistono solo lì, non sul branch precedente.

Storicamente si usava git checkout <branch> per switchare — funziona ancora, ma checkout fa mille altre cose; switch esiste apposta per essere semplice. Vecchi tutorial useranno checkout: entrambi validi.

Dopo lo switch, i commit fatti sul branch nuovo divergono dal branch principale: due timeline indipendenti.

Creare E passare in un colpo solo

git switch -c refactor    # -c = create

Branch dentro branch

Un branch nasce sempre dall’HEAD: se crei un branch mentre sei su bugfix, il nuovo branch include tutti i commit di bugfix (è una timeline che parte da quella).

Eliminare un branch

git branch -d bugfix

Dopo il merge, i commit restano nella history del branch di destinazione: eliminare il branch elimina solo il puntatore.

---

Immagini: documentazione ufficiale di Git (git-scm.com, dal libro Pro Git di Scott Chacon), licenza CC BY-NC-SA 3.0.