Git Flow: cos’è, modello di ramificazione e utilizzo nei progetti

Cos’è Git Flow?

Git Flow è un modello di ramificazione Git che definisce una struttura rigorosa di branch e regole di merge per gestire sviluppo, rilasci e correzioni. Vincent Driessen ha pubblicato l’articolo “A successful Git branching model” nel gennaio 2010, e da allora Git Flow è diventato lo standard de facto nello sviluppo aziendale Java e .NET. L’idea principale è dividere il codice in cinque tipi di branch con diversi livelli di stabilità.

Secondo Atlassian Git Tutorials, 2024, Git Flow si basa su due branch perpetui: main (precedentemente master) e develop. Tutti gli altri branch sono temporanei: feature, release, hotfix. Ogni tipo di branch ha un ciclo di vita e regole di merge chiaramente definiti. Nello sviluppo mobile, Git Flow viene utilizzato in progetti con cicli di rilascio regolari (2–4 settimane) e supporto per più versioni.

Git Flow si differenzia dai modelli semplici (GitHub Flow) per la necessità di un branch develop separato per l’integrazione. Questo aggiunge un passaggio al processo di merge, ma fornisce un isolamento aggiuntivo delle funzionalità non finite dal codice pronto per il rilascio.

Vincent Driessen e la storia di Git Flow

Nel 2010, Vincent Driessen ha pubblicato il post “A successful Git branching model”, che è diventato uno dei più citati nella storia di Git. Il modello è stato creato per un progetto con rilasci fissi e supporto parallelo delle versioni. Nel 2020, Driessen ha riconosciuto che Git Flow è obsoleto per le pratiche moderne di CI/CD, ma il modello rimane rilevante per progetti con lunghi cicli di rilascio e la necessità di supportare versioni precedenti.

# Inizializzare Git Flow
git flow init

# Creare un branch feature
git flow feature start "add-auth"

# Completare il branch feature (merge in develop)
git flow feature finish "add-auth"

# Creare un release
git flow release start "1.2.0"
git flow release finish "1.2.0"

Branch Main: codice di rilascio e tagging

Main (precedentemente master) è il branch principale che contiene solo il codice di rilascio pronto per il deployment. Ogni commit in main deve corrispondere a una versione specifica del prodotto, taggata nel formato di versionamento semantico, ad esempio v1.0.0, v1.1.0. Nessuno sviluppo diretto viene effettuato in main — le modifiche arrivano qui solo attraverso i branch release o hotfix.

Secondo semver.org, 2024, i tag in main usano il formato MAJOR.MINOR.PATCH. MAJOR viene incrementato per modifiche API incompatibili, MINOR per l’aggiunta di funzionalità con compatibilità all’indietro, PATCH per correzioni di bug. In Git Flow, ogni completamento di release crea automaticamente un commit in main con un tag di versione.

Il branch Main è l’unico distribuito in produzione. Per i progetti mobili, ciò significa che un push in main attiva la pipeline di build dell’App Bundle o IPA e la pubblicazione su Google Play / App Store. Nelle impostazioni CI/CD di GitLab, main è protetta da force-push ed eliminazione.

Versionamento semantico e tag

Ogni commit in main è accompagnato da un tag in formato SemVer: vMAJOR.MINOR.PATCH. MAJOR — per modifiche API incompatibili, MINOR — per nuove funzionalità con compatibilità all’indietro, PATCH — per correzioni di bug. Esempio: v2.1.0 significa il secondo rilascio principale con nuove funzionalità e senza correzioni di bug. In Git Flow, i tag vengono creati automaticamente al completamento di un release o hotfix tramite il comando git flow release finish.

Branch Develop: linea di integrazione dello sviluppo

Develop è il secondo branch perpetuo in Git Flow, progettato per integrare tutte le funzionalità completate. Gli sviluppator mergeano i branch feature in develop dopo aver superato la revisione del codice e i controlli CI/CD. Develop contiene l’ultima versione stabile del codice, incluse tutte le funzionalità implementate dello sprint corrente.

Secondo DataSift Git Flow Guide, 2024, develop può essere temporaneamente instabile a causa di integrazioni in corso. Per prevenire problemi, i team praticano l’Integrazione Continua (CI): ogni funzionalità deve superare una suite di test completa prima di essere mergiata in develop. Se la CI fallisce, lo sviluppatore corregge il codice prima del merge successivo. Develop è sempre legata alla versione corrente di main: immediatamente dopo un rilascio, develop viene sincronizzata con main tramite un merge.

Branch Feature: sviluppo di nuove funzionalità

I branch Feature sono branch temporanei per lo sviluppo di funzionalità individuali, correzioni di bug o esperimenti. Ogni branch feature viene creato da develop e mergiato in develop dopo il completamento. Il nome del branch feature di solito contiene il numero del task o una breve descrizione: feature/APP-123-add-oauth, feature/redesign-profile. In Git Flow, i branch feature possono esistere indefinitamente.

Secondo Pro Git Book, 2024, i branch feature sono un ambiente di sviluppo isolato: le modifiche in un branch non influenzano gli altri fino al merge. Nei progetti mobili, i branch feature vengono sincronizzati con develop tramite rebase o merge per evitare grandi conflitti al completamento. Si consiglia di fare rebase del branch feature su develop prima di creare un MR.

# Creazione manuale del branch feature (senza git flow)
git checkout -b feature/APP-142-add-auth develop
git commit -m "Add OAuth2 authentication with Google"
git push origin feature/APP-142-add-auth

# Creare MR in GitLab tramite CLI
glab mr create \
    --source-branch "feature/APP-142-add-auth" \
    --target-branch "develop" \
    --title "Add OAuth2 authentication"

Branch Release: preparazione di un rilascio

I branch Release sono branch temporanei creati da develop per preparare un rilascio. Quando develop contiene funzionalità sufficienti per una nuova versione, il team crea un branch release/X.Y.Z (ad esempio, release/2.1.0). In questo branch vengono apportate solo modifiche finali: incremento della versione, aggiornamento della localizzazione, test finali, correzione di bug critici.

Secondo Atlassian Git Tutorials, 2024, il branch release risolve un problema chiave: isolare le modifiche finali dallo sviluppo parallelo. Mentre il rilascio viene preparato, nuove funzionalità per il rilascio successivo continuano a essere mergiate in develop. Dopo il completamento, il branch release viene mergiato in main (con un tag) e in develop (per sincronizzare l’incremento della versione).

Branch Hotfix: correzioni urgenti in produzione

I branch Hotfix sono branch temporanei per correggere urgentemente bug critici in produzione. L’unico tipo di branch in Git Flow che viene creato da main invece che da develop. Formato del nome: hotfix/X.Y.Z+1 (ad esempio, hotfix/2.1.1). Dopo il completamento, il branch hotfix viene mergiato simultaneamente in main (come una nuova patch release) e in develop (in modo che la correzione non venga persa nei rilasci futuri).

Secondo DataSift Git Flow Guide, 2024, i branch hotfix dovrebbero essere il più brevi possibile — solo la correzione e il test. Un hotfix non deve includere nuove funzionalità o refactoring. Nello sviluppo mobile, hotfix viene utilizzato per correggere crash critici (tasso di crash > 0,1%), vulnerabilità di sicurezza o bug bloccanti nell’App Store.

Pro e contro di Git Flow per lo sviluppo mobile

Git Flow fornisce una struttura chiara che è particolarmente utile per grandi team e progetti con rilasci regolari. Pro: isolamento delle funzionalità non finite nei branch feature, possibilità di preparare un rilascio senza bloccare lo sviluppo, supporto di più versioni tramite hotfix. Contro: complessità per i principianti, necessità di rebase regolare dei branch feature, conflitti con branch di lunga durata.

Secondo Martin Fowler, 2024, il principale svantaggio di Git Flow sono i branch feature di lunga durata. Se una funzionalità viene sviluppata per 2+ settimane senza sincronizzazione con develop, il conflitto di merge diventa significativo. Per i progetti mobili, si consiglia di sincronizzare il branch feature quotidianamente tramite rebase su develop.

Git Flow non è raccomandato per progetti con Continuous Deployment (ogni commit in main → produzione). Per tali progetti, GitHub Flow o Trunk-Based Development forniscono un modello più semplice e veloce. Ma per progetti con cicli di rilascio e supporto di versioni precedenti, Git Flow rimane la scelta ottimale.

Quando Git Flow è dannoso per il team

Git Flow diventa un problema in tre casi: team con meno di 5 persone (complessità inutile), Continuous Deployment (ritardo nella consegna), mancanza di disciplina di rebase (i branch feature di lunga durata creano conflitti di merge). Se un team spende più del 20% del tempo a mergiare branch e risolvere conflitti — Git Flow non è adatto a quel team, anche se è grande.

Alternative a Git Flow: GitHub Flow e Trunk-Based Development

Le alternative a Git Flow offrono un processo più semplice per i team che praticano CI/CD. GitHub Flow utilizza un solo branch perpetuo (main) e branch feature. Ogni funzionalità viene creata da main, dopo revisione e CI viene mergiata in main e immediatamente distribuita. GitHub Flow è più semplice ma non supporta l’isolamento delle funzionalità non finite o la preparazione parallela dei rilasci.

Secondo GitHub Docs, 2024, Trunk-Based Development (TBD) va ancora oltre: tutti gli sviluppatori lavorano in un unico branch (trunk), utilizzando branch feature di breve durata di 1–2 giorni. I feature toggles controllano la visibilità del codice non finito. TBD richiede un’elevata disciplina CI/CD e automazione dei test.

• GitHub Flow — un main + branch feature, ideale per CI/CD e team piccoli
• GitLab Flow — estende Git Flow con branch di ambiente (staging, production)
• Trunk-Based Development — un branch + feature toggles, massimo CI/CD, minimi merge
• One Flow — Git Flow semplificato senza branch develop, solo main + feature + release