Strategie di branching: short-lived vs long-lived

Un branch è economico da creare, ma non è gratuito da mantenere. Più vive, più diverge. Più diverge, più costoso diventa integrarlo.

La strategia di branching non è una religione: dipende da prodotto, team, ciclo di rilascio, test automatici e tolleranza al rischio.

Perché questa lezione conta

Branch vecchi sono una forma di debito tecnico. Nascondono lavoro non integrato, accumulano conflitti, rendono i test meno significativi e creano sorprese al merge.

Allo stesso tempo, alcuni prodotti hanno bisogno di release branch o supporto a più versioni. L’obiettivo è scegliere consapevolmente, non ripetere una ricetta.

Obiettivo operativo

Alla fine della lezione devi saper valutare quando usare branch short-lived, quando accettare branch long-lived e quali pratiche riducono il costo della divergenza.

Branch short-lived

Durano ore o pochi giorni. Tipici di trunk-based development e GitHub Flow leggero.

Vantaggi:

1. conflitti piccoli;
2. feedback rapido da CI;
3. review più semplice;
4. minor distanza da main;
5. meno lavoro nascosto.

Richiedono:

1. test automatici;
2. feature flag per codice non ancora attivo;
3. PR piccole;
4. capacità di spezzare lavoro grande.

Branch long-lived

Durano settimane o mesi. Possono avere senso per:

1. release branch di prodotto versionato;
2. supporto a clienti su versioni diverse;
3. migrazioni lunghe isolate;
4. sviluppo sperimentale non pronto.

Costi:

1. conflitti grandi;
2. integrazione dolorosa;
3. CI meno rappresentativa;
4. rischio “funziona sul mio branch”;
5. review enorme alla fine.

Se un branch deve vivere a lungo, va trattato come un progetto: sincronizzazioni pianificate, owner, criteri di merge, test regolari.

Misurare età e stato

Comandi utili:

git branch --sort=-committerdate
git branch -vv
git for-each-ref --sort=-committerdate refs/heads/ --format='%(committerdate:short) %(refname:short)'

Per branch remoti:

git fetch --prune
git branch -r --sort=-committerdate

Non basta sapere quanti branch ci sono. Serve sapere quali sono vivi, quali integrati, quali abbandonati.

Costo della divergenza

Un branch diverge quando main continua a muoversi e il branch resta indietro.

Riduci il costo con:

1. rebase o merge frequente da main;
2. PR piccole;
3. feature flag;
4. commit atomici;
5. eliminazione branch dopo merge;
6. ownership chiara.

Il problema non è il branch. È il branch senza ciclo di vita.

Policy di team

Esempio:

Feature branch: massimo 2-3 giorni.
Spike: massimo 1 settimana, poi decisione.
Release branch: owner e data di chiusura.
Branch remoti mergiati: cancellati entro 24h.
Branch stale > 14 giorni: review settimanale.

Una policy semplice evita accumulo silenzioso.

Laboratorio guidato

Nel tuo repo:

1. esegui fetch con prune;
2. lista branch locali e remoti per data;
3. classifica: attivo, mergiato, abbandonato, release, spike;
4. cancella branch locali sicuri;
5. proponi cancellazione remota dove serve;
6. scrivi una regola di durata per il team.

Non cancellare branch remoti condivisi senza accordo.

Output atteso

Una tabella:

branch | owner | età | stato | azione

e una policy di branching di massimo 10 righe.

Errori comuni

Confondere branch vecchio con branch importante. Se è importante, deve avere owner e piano.

Integrare solo alla fine. Rende i conflitti più costosi.

Tenere branch remoti mergiati. Sporcono la vista e confondono.

Usare long-lived per paura del rilascio. Spesso servono feature flag o test, non branch eterni.

Checklist di verifica

• so misurare età dei branch;
• so distinguere branch attivo, stale e release;
• so cancellare branch locali sicuri;
• il team ha una durata attesa per feature branch;
• i branch lunghi hanno owner e motivazione.

Collegamenti

• Modulo: Branch e merge — lezione 15 del corso.
• I workflow del modulo 6 formalizzano queste scelte a livello di team.