Workflow con feature branch

Panoramica

Il workflow con feature branch è il modo più comune con cui i team collaborano usando Git. La regola è semplice: tutto lo sviluppo avviene su branch dedicati, mai direttamente su main. Ogni nuova funzionalità, correzione o esperimento riceve il proprio branch, e il branch main riceve solo lavoro completato e revisionato. Questo mantiene main stabile e pronto per il rilascio in ogni momento.

L'idea centrale

Poiché il lavoro è isolato sui branch, più persone possono sviluppare funzionalità diverse in parallelo senza interferire. main funge da unica fonte di verità per il codice pronto per la produzione. Un branch è un'unità di lavoro focalizzata che ha un inizio chiaro (creato da main) e una fine chiara (unito di nuovo a main).

È fondamentale notare che un branch in Git è economico: è semplicemente un puntatore mobile a un commit, non una copia dei tuoi file. Crearne uno è istantaneo e utilizza quasi nessuno spazio su disco, ed è esattamente per questo che creare un branch per ogni attività è pratico.

Denominare i branch

Uno schema di denominazione coerente rende i branch auto-documentanti. La maggior parte dei team prefissa il branch con il suo tipo e fa riferimento all'attività su cui si sta lavorando:

feature/login-form
feature/W3-142-checkout-page
fix/null-pointer-on-logout
chore/upgrade-eslint

Lo slash è solo una convenzione — Git tratta feature/login-form come un singolo nome di branch, anche se permette agli strumenti di raggruppare i branch per prefisso. Evita spazi e lettere maiuscole per mantenere i nomi facili da digitare.

Un esempio passo dopo passo

Il workflow è un ciclo breve e ripetibile: crea un branch da main, lavora, fai il push, rivedi, unisci, pulisci.

1. Crea il branch da un main aggiornato

Inizia sempre dall'ultimo main in modo che il tuo branch sia basato sul codice attuale:

git switch main
git pull
git switch -c feature/login-form

git switch -c crea il branch ed esegue il checkout in un unico passaggio (l'equivalente precedente è git checkout -b). Consulta git switch per il comando completo.

2. Lavora, facendo commit progressivamente

Esegui commit in passi piccoli e logici piuttosto che un unico commit gigante alla fine — i commit piccoli sono più facili da revisionare e da annullare:

git add login.html login.js
git commit -m "Add login form markup and validation"

Preferisci mettere in stage file specifici invece di git add . per non fare accidentalmente commit di modifiche non correlate. Leggi di più su come creare buoni commit in git commit.

3. Fai il push del branch

Esegui il push in modo che i tuoi colleghi possano vedere il tuo lavoro e tu possa aprire una pull request. Il flag -u collega il tuo branch locale a quello remoto, così in seguito potrai digitare semplicemente git push:

git push -u origin feature/login-form

Consulta git push per i dettagli su cosa fa -u (--set-upstream).

Revisione e unione

Su una piattaforma di hosting come GitHub o GitLab, apri una pull request (PR), chiamata merge request su GitLab. Qui i colleghi revisionano il diff, lasciano commenti e approvano. I controlli di integrazione continua (CI) di solito eseguono la suite di test sul branch automaticamente. Una volta che la PR è approvata e i controlli sono verdi, il branch viene unito a main.

Le piattaforme offrono tre strategie di unione comuni:

• Merge commit — conserva ogni commit sul branch più un merge commit. Mantiene la cronologia completa ma può risultare rumoroso.
• Squash and merge — comprime tutti i commit del branch in un unico commit ordinato su main. Molto usato perché main rimane pulito e ogni funzionalità è una singola voce.
• Rebase and merge — riapplica i commit del branch su main senza un merge commit, ottenendo una cronologia lineare.

Pulire dopo l'unione

Una volta che il branch è stato unito, eliminalo localmente e in remoto in modo che il repository non si riempia di branch obsoleti:

git switch main
git pull
git branch -d feature/login-form        # delete the local branch
git push origin --delete feature/login-form   # delete the remote branch

git branch -d rifiuta di eliminare un branch che non è stato unito, proteggendoti dalla perdita di lavoro. (Usa -D per forzare l'eliminazione quando sei sicuro.)

Mantenere un branch aggiornato

Se main avanza mentre lavori, porta quelle modifiche nel tuo branch in modo che l'unione finale sia fluida e i conflitti emergano presto. Hai due opzioni:

# Option A — merge main into your branch (keeps history as-is)
git switch feature/login-form
git merge main

# Option B — rebase your branch onto the latest main (linear history)
git switch feature/login-form
git rebase main

Il merge è non distruttivo e sicuro per i branch condivisi, ma aggiunge merge commit. Il rebase produce una cronologia più pulita e lineare ma riscrive i commit del tuo branch — quindi evita di fare rebase su un branch che altri hanno già scaricato. La regola pratica: fai rebase sul tuo branch privato, usa merge per tutto ciò che è condiviso.

Gestire i conflitti

Quando due branch modificano le stesse righe, il merge o il rebase si interrompe e ti chiede di risolvere il conflitto. Git segna le regioni in conflitto nei file interessati; le modifichi, poi esegui lo stage e continui. L'intero processo è descritto in Risolvere i conflitti di merge.

Salvare il lavoro in corso

Se devi cambiare branch ma non sei pronto a fare un commit, git stash mette da parte le tue modifiche non committate in modo che tu possa spostarti liberamente e ripristinarle in seguito:

git stash            # set current changes aside
git switch main      # do something urgent
git switch feature/login-form
git stash pop        # bring the changes back

Vantaggi e compromessi

Il workflow con feature branch è popolare perché è facile da capire, si integra naturalmente con le pull request e la revisione del codice, e mantiene main sempre pronto per il rilascio.

Il suo rischio principale sono i branch longevi: più a lungo vive un branch, più si discosta da main e più difficile diventa l'unione finale ("merge hell"). Per evitarlo:

• Mantieni i branch piccoli e di breve durata — idealmente uniti entro uno o due giorni.
• Porta main nel tuo branch (o esegui il rebase) regolarmente, non solo alla fine.
• Suddividi le funzionalità grandi in diversi branch più piccoli che si uniscono indipendentemente.
• Non fare mai commit direttamente su main — questo vanifica lo scopo del workflow.

Quando i team hanno bisogno di branch di rilascio, branch per hotfix e un rigoroso processo di promozione su tutto questo, spesso adottano un modello più completo come Git Flow o lo sviluppo trunk-based — ma il feature branch è il blocco di costruzione alla base di tutti questi modelli.

Pratica