Git Flow vs trunk-based: quale strategia di branching
Git Flow, GitHub Flow e trunk-based development a confronto: come funzionano, quando serve ciascuno e perché oggi si tende alla semplicità.
Una volta deciso di usare i rami, resta la domanda successiva: come li si organizza in un team? Esistono modelli consolidati, e il più famoso — Git Flow — è anche quello che oggi viene sconsigliato nella maggior parte dei casi, incluso da chi lo ha inventato. In questo articolo trovi le tre strategie principali e il criterio per scegliere.
Il problema che risolvono
Una strategia di branching è un accordo su quali rami esistono, chi ci lavora, e come il codice passa dallo sviluppo alla produzione.
Senza un accordo, in un team succede il prevedibile: nessuno sa quale ramo contiene cosa, si integra a caso, e prima o poi va in produzione qualcosa che non doveva.
Il concetto tecnico di ramo è in Git branch: come funzionano i rami; qui parliamo di come organizzarli.
Git Flow
Il modello più strutturato, proposto nel 2010 e diventato per anni lo standard di riferimento.
I rami previsti:
main— il codice in produzione, ogni commit è una versione rilasciatadevelop— l'integrazione dello sviluppo in corsofeature/*— una per funzionalità, partono dadeveloprelease/*— preparazione di un rilascio, stabilizzazionehotfix/*— correzioni urgenti, partono damain
Il flusso: sviluppi su una feature, la integri in develop, quando è ora di rilasciare apri una release, la stabilizzi, la porti in main e la riporti anche in develop.
A cosa serve davvero: software con versioni distribuite e supportate nel tempo. Applicazioni installate, librerie con più versioni attive, prodotti dove i clienti usano versioni diverse.
Perché oggi si usa meno: è pesante. Due rami permanenti da tenere allineati, rami di rilascio, integrazioni doppie. Su un'applicazione web che si aggiorna più volte al giorno, questa struttura è quasi tutta sovraccarico, e lo stesso autore ha poi scritto pubblicamente che per lo sviluppo web continuo non è il modello adatto.
GitHub Flow
La semplificazione radicale, ed è probabilmente il modello più diffuso oggi.
Un solo ramo permanente: main, sempre rilasciabile.
Il flusso completo:
- Crei un ramo da
main - Ci lavori
- Apri una pull request
- Revisione e controlli automatici
- Integri in
main - Rilasci
Niente develop, niente rami di rilascio. Ogni integrazione in main può andare in produzione.
A cosa serve: applicazioni web, servizi, qualunque cosa dove esiste una sola versione attiva — quella online.
Cosa richiede per funzionare: test automatici affidabili, perché non c'è un ramo di stabilizzazione che faccia da rete. Se i test non sono buoni, questo modello mette in produzione i problemi.
Trunk-based development
L'estremo opposto di Git Flow.
Tutti lavorano direttamente sul ramo principale, o su rami che vivono poche ore. L'integrazione avviene più volte al giorno, per ogni persona.
Sembra pericoloso, e la domanda ovvia è: come si rilascia qualcosa a metà?
La risposta sono i feature flag. Il codice incompleto viene integrato ma resta disattivato da un interruttore, e si accende quando è pronto. Separa il momento in cui il codice va in produzione dal momento in cui diventa visibile agli utenti — che è una distinzione potente e sottovalutata.
A cosa serve: team maturi con integrazione continua solida, che rilasciano molto spesso.
Cosa richiede: test automatici eccellenti, cultura della revisione rapida, e la disciplina dei feature flag — che vanno anche rimossi dopo, altrimenti il codice si riempie di condizioni morte.
Il vantaggio principale, quello che conta davvero: i conflitti quasi spariscono. Integrando ogni poche ore, non c'è tempo perché i rami divergano. È il rimedio strutturale al problema descritto in risolvere i conflitti in Git.
Il confronto
| Git Flow | GitHub Flow | Trunk-based | |
|---|---|---|---|
| Rami permanenti | 2 | 1 | 1 |
| Durata dei rami | Giorni/settimane | Giorni | Ore |
| Complessità | Alta | Bassa | Bassa (ma esigente) |
| Conflitti | Frequenti | Medi | Rari |
| Serve CI solida | Utile | Sì | Indispensabile |
| Rilasci | Programmati | Frequenti | Continui |
| Adatto a | Software versionato | App web | Team maturi |
Come scegliere
Il criterio pratico, in tre domande:
1. I tuoi utenti usano versioni diverse contemporaneamente?
Se sì — software installato, librerie, prodotti con supporto a lungo termine — serve una struttura tipo Git Flow, perché devi poter correggere una versione vecchia senza portarci dentro le novità.
Se no — esiste solo ciò che è online — quella struttura è sovraccarico.
2. Quanto sono buoni i tuoi test automatici?
Senza test affidabili, trunk-based è pericoloso e GitHub Flow è rischioso. La qualità della verifica automatica determina quanto puoi semplificare il processo.
3. Quanto spesso rilasciate?
Una volta al mese → Git Flow ha senso. Ogni settimana → GitHub Flow. Più volte al giorno → trunk-based.
Per la stragrande maggioranza dei progetti — applicazioni web, team piccoli, freelance — GitHub Flow è la risposta giusta, e non serve nemmeno chiamarlo così: un ramo per funzionalità, revisione, integrazione.
Gli errori comuni
Adottare Git Flow "perché è lo standard". Non lo è più, e su un'applicazione web è complessità pura. È l'errore più diffuso.
Rami lunghi in qualunque modello. La durata dei rami è la variabile che conta più della strategia scelta: due settimane separati producono conflitti in Git Flow come altrove.
Trunk-based senza feature flag. Integrare codice incompleto senza un interruttore significa mandare in produzione roba a metà.
Cambiare modello senza scriverlo. Se metà del team segue una convenzione e metà un'altra, il risultato è peggio di entrambe.
Non pulire i feature flag. Dopo sei mesi il codice è pieno di condizioni che non spegnerà più nessuno — un caso da manuale di debito tecnico.
Una nota sulle protezioni
Qualunque modello scegliate, due impostazioni valgono sempre la pena sul ramo principale:
Vietare l'invio diretto, obbligando a passare da una proposta di modifica.
Richiedere che i controlli automatici passino prima dell'integrazione — le GitHub Actions o equivalenti.
Sono cinque minuti di configurazione che impediscono l'intera categoria di incidenti del tipo "ho inviato per sbaglio su main".
In sintesi
Le strategie sono tre. Git Flow è strutturato e adatto al software con versioni multiple attive; su un'applicazione web è quasi tutto sovraccarico. GitHub Flow tiene un solo ramo sempre rilasciabile ed è la scelta sensata per la maggior parte dei progetti. Trunk-based integra più volte al giorno e fa quasi sparire i conflitti, ma richiede test eccellenti e feature flag.
La domanda che decide: i tuoi utenti usano versioni diverse contemporaneamente? Se no, il modello semplice basta.
E la variabile che conta più della strategia stessa: quanto durano i rami. Rami brevi funzionano in qualunque modello; rami lunghi creano problemi in tutti.
Contenuto redatto con l'assistenza di strumenti di intelligenza artificiale e rivisto dalla redazione di Codegrind, che ne è responsabile. Hai trovato un errore? Scrivici.