GitFlow e release branch: quando ha ancora senso

GitFlow organizza la storia con branch a ruolo: main, develop, feature/*, release/*, hotfix/*. È più strutturato di GitHub Flow e trunk-based.

Non è morto, ma non è il default giusto per ogni progetto. Ha senso quando il ciclo di release richiede separare sviluppo, stabilizzazione e hotfix.

Perché questa lezione conta

Molti team usano GitFlow perché “si è sempre fatto così”, anche su prodotti web che rilasciano più volte al giorno. Altri lo scartano senza capire perché alcuni prodotti ne hanno ancora bisogno.

La competenza reale è riconoscere il contesto.

Obiettivo operativo

Alla fine della lezione devi saper descrivere GitFlow, disegnare un ciclo release/hotfix e decidere se è adatto al tuo progetto.

Branch principali

main       -> codice rilasciato
develop    -> integrazione sviluppo
feature/*  -> lavoro singolo
release/*  -> stabilizzazione versione
hotfix/*   -> correzione urgente da main

Flusso tipico:

feature -> develop -> release -> main
                           \-> tag
hotfix -> main -> develop

Quando ha senso

GitFlow può avere senso per:

1. librerie versionate;
2. app desktop/mobile con review store;
3. software installato presso clienti;
4. prodotti con supporto a versioni vecchie;
5. release pianificate e stabilizzazione;
6. hotfix su versioni già rilasciate.

Qui release/1.4 è utile: congela la versione, accetta solo fix, prepara changelog e tag.

Costo operativo

GitFlow richiede disciplina continua: branch mantenuti, merge back, tag coerenti, changelog, hotfix doppi e comunicazione sulle release. Questo costo è giustificato solo se riduce un rischio reale.

La domanda pratica non è “GitFlow è moderno?”. La domanda è: il nostro prodotto ha bisogno di stabilizzare una versione mentre lo sviluppo successivo continua altrove? Se la risposta è no, GitFlow probabilmente sta pagando complessità senza restituire controllo.

Quando è overkill

È spesso eccessivo per:

1. SaaS a deploy continuo;
2. siti web piccoli;
3. team di 1-5 persone;
4. progetti con un solo ambiente;
5. codice rilasciato sempre da main;
6. team che non mantengono versioni vecchie.

In questi casi aggiunge branch, merge e ritardi senza vero beneficio.

Release branch

Esempio:

git switch develop
git switch -c release/1.4
# fix di stabilizzazione
git switch main
git merge --no-ff release/1.4
git tag -a v1.4.0 -m "Release 1.4.0"
git switch develop
git merge --no-ff release/1.4

Il merge verso develop riporta i fix fatti durante stabilizzazione.

Hotfix

git switch main
git switch -c hotfix/1.4.1-login
# fix
git switch main
git merge --no-ff hotfix/1.4.1-login
git tag -a v1.4.1 -m "Hotfix 1.4.1"
git switch develop
git merge --no-ff hotfix/1.4.1-login

Il fix deve arrivare sia nella versione rilasciata sia nello sviluppo futuro.

Laboratorio guidato

Disegna un rilascio:

1. due feature su develop;
2. creazione release/1.0;
3. fix su release;
4. merge in main e tag;
5. merge back in develop;
6. hotfix da main;
7. merge hotfix in main e develop.

Poi rispondi: questo processo è necessario nel tuo progetto o basterebbe GitHub Flow?

Output atteso

Una decisione:

Workflow scelto:
Motivo:
Branch principali:
Quando aprire release branch:
Quando aprire hotfix:
Quando taggare:

Errori comuni

Usare GitFlow senza release reali. Aggiunge complessità inutile.

Dimenticare merge back. Fix su release/hotfix devono tornare nello sviluppo.

Tenere develop instabile per sempre. Allora la stabilizzazione diventa lunga e dolorosa.

Confondere release branch con branch feature lungo. Hanno scopi diversi.

Checklist di verifica

• so spiegare ruolo di main e develop;
• so disegnare release e hotfix;
• so quando taggare;
• so quando GitFlow è overkill;
• il team ha criteri per aprire release branch.

Collegamenti

• Modulo: Workflow di team — lezione 28 del corso.
• Tag e SemVer completano il discorso release.