Il tuo team sta perdendo tempo a risolvere conflitti su Git invece di scrivere codice? O peggio, state facendo merge di feature branch con giorni di ritardo e la pipeline di produzione si blocca. Questo è il problema concreto che affrontiamo ogni giorno con i team che seguiamo. Non è una questione di preferenze personali: la scelta tra Gitflow e trunk-based development impatta direttamente la velocità di rilascio, la stabilità del codice e il morale del team.
Noi, di Meteora Web, abbiamo visto progetti bloccati da strategie di branching sbagliate. Branch che vivono settimane, merge che diventano incubi, e release che si accumulano. In questa guida confrontiamo le due strategie principali — Gitflow e trunk-based development — per capire quale si adatta al tuo contesto e come implementarla senza dolore.
Cos'è Gitflow e come funziona nel flusso di lavoro quotidiano?
Gitflow è una strategia di branching che introduce una rigida struttura di branch per gestire lo sviluppo, le release e le hotfix. È stata formalizzata da Vincent Driessen nel 2010 e ha dominato la scena per anni. Il modello prevede branch principali come main e develop, e branch di supporto come feature, release e hotfix.
Il ciclo di vita è chiaro: ogni nuova funzionalità parte da develop e vive in un branch feature. Quando è pronta, si fa merge in develop. Quando si prepara una release, si crea un branch release da develop, si stabilizza, e si fa merge sia in main che in develop. Le hotfix partono da main e vengono integrate ovunque.
Quali sono i vantaggi concreti di Gitflow per un team strutturato?
Il vantaggio principale è la tracciabilità. Ogni branch ha un ruolo preciso, e questo facilita la gestione di release pianificate. Per team che lavorano su versioni multiple di un prodotto — pensa a un software con versioni LTS — Gitflow offre un controllo granulare. Inoltre, la separazione netta tra codice stabile (main) e codice in sviluppo (develop) protegge la produzione.
Sponsored Protocol
Abbiamo visto team usare Gitflow con successo in contesti enterprise dove il rilascio è un evento formale, con date precise e procedure di QA. In questi casi, la struttura rigida è un vantaggio, non un limite.
Quando Gitflow diventa un peso invece che un aiuto?
Il problema emerge quando il team vuole rilasciare frequentemente. Con Gitflow, ogni release richiede una serie di passaggi: creare il branch release, testarlo, fare merge, aggiornare develop. Se il tuo team fa deploy più volte al giorno, questa struttura diventa un collo di bottiglia. Inoltre, i branch feature che vivono a lungo — tipici di Gitflow — aumentano la probabilità di conflitti e rendono il merge finale un'operazione complessa.
Un altro aspetto critico è la gestione delle hotfix. In Gitflow, una hotfix richiede merge multipli (in main e develop, e spesso anche nei branch release attivi). Con il tempo, questa manutenzione continua può introdurre errori e confusione.
Cos'è il trunk-based development e perché sta sostituendo Gitflow nei team moderni?
Il trunk-based development capovolge la logica di Gitflow. Tutti gli sviluppatori lavorano su un unico branch condiviso — il trunk (o main) — e integrano le loro modifiche frequentemente, idealmente più volte al giorno. Le feature branch esistono, ma sono di breve durata, spesso poche ore o al massimo un paio di giorni.
Il principio fondamentale è semplice: più piccola è l'integrazione, minore è il conflitto. Invece di nascondere il codice in branch per settimane, lo condividi subito con il team. Questo obbliga a scrivere codice modulare e a mantenere il trunk sempre in uno stato rilasciabile.
Come si gestisce il rilascio nel trunk-based development?
Nel trunk-based development, il rilascio è un'operazione continua. Il codice nel trunk è sempre pronto per la produzione. Le release vengono taggate dal trunk, e se serve una hotfix, si corregge direttamente sul trunk e si rilascia immediatamente. Niente merge multipli, niente branch di stabilizzazione.
Sponsored Protocol
Questa strategia funziona benissimo con le pipeline CI/CD moderne. Ogni commit che arriva sul trunk attiva una build, una serie di test automatici e, se tutto passa, un deploy in staging o direttamente in produzione. Il feedback è immediato e gli errori vengono scoperti subito, quando sono ancora facili da correggere.
Quali sono le sfide del trunk-based development per un team abituato a Gitflow?
La sfida principale è culturale. I team abituati a Gitflow trovano difficile rinunciare alla sicurezza di un branch separato. La paura di rompere il trunk è reale. Ma con una buona suite di test automatici e una pipeline solida, questa paura si dissolve. Un'altra sfida è la disciplina: richiede che ogni modifica sia piccola, testata e integrata rapidamente. Non è una strategia per chi lavora in silos o per chi non ha una cultura del testing.
Noi, di Meteora Web, abbiamo visto team passare a trunk-based development e ridurre i tempi di integrazione del 70%. Ma richiede investimento nella pipeline e nella formazione. Non è una bacchetta magica, è un cambio di mentalità.
Gitflow vs trunk-based development — come scegliere la strategia giusta per il tuo team?
La scelta non è una questione di moda, ma di contesto. Ecco i fattori che valutiamo con i nostri clienti prima di consigliare una strategia.
Fattore 1 — Frequenza di rilascio
Se rilasci una volta al mese o a release pianificate, Gitflow ti dà struttura e controllo. Se rilasci più volte al giorno o vuoi arrivarci, trunk-based development è la scelta obbligata. La frequenza di rilascio è il primo indicatore da guardare.
Sponsored Protocol
Fattore 2 — Dimensione e autonomia del team
Un team piccolo (2-5 sviluppatori) che lavora sulla stessa base di codice trae enormi benefici dal trunk-based development. La comunicazione è diretta e i conflitti sono rari se si integra spesso. Un team grande (20+ sviluppatori) su progetti complessi può ancora usare trunk-based, ma richiede una disciplina ferrea e feature flag per nascondere codice incompleto.
Fattore 3 — Complessità del prodotto e supporto versioni multiple
Se devi mantenere più versioni del software in produzione contemporaneamente — pensa a un prodotto con versioni LTS o a un'app desktop — Gitflow offre una gestione più chiara. Il trunk-based development presuppone che tu possa sempre rilasciare l'ultima versione del trunk. Per applicazioni web o SaaS, trunk-based è quasi sempre la scelta migliore.
Quali strumenti e pratiche rendono efficace il trunk-based development?
Se decidi di adottare trunk-based development, ci sono strumenti e pratiche che rendono il passaggio molto più fluido.
Feature flag per nascondere codice incompleto
Il problema numero uno con il trunk-based è il codice incompleto. La soluzione sono i feature flag: variabili che attivano o disattivano una funzionalità a runtime. Puoi integrare codice non finito nel trunk senza che venga attivato in produzione. Questo elimina la necessità di branch di lunga durata.
// Esempio di feature flag semplice
const isFeatureEnabled = (featureName) => {
const flags = {
'new-checkout': process.env.NEW_CHECKOUT === 'true',
'dark-mode': process.env.DARK_MODE === 'true'
};
return flags[featureName] || false;
};
// Uso nel codice
if (isFeatureEnabled('new-checkout')) {
renderNewCheckout();
} else {
renderOldCheckout();
}Pull request piccole e frequenti
Le pull request non spariscono nel trunk-based development, ma cambiano natura. Devono essere piccole (meno di 200 righe), focalizzate su una singola funzionalità, e aperte e chiuse nello stesso giorno. Se una PR resta aperta per più di due giorni, è un segnale che il branch è troppo grande e va spezzato.
Sponsored Protocol
Pipeline CI/CD solida e test automatici
La pipeline è il cuore del trunk-based development. Ogni push sul trunk deve attivare una build, eseguire test unitari, test di integrazione e analisi statica del codice. Se qualcosa fallisce, il team deve fermare tutto e correggere. È questa disciplina che mantiene il trunk sempre verde e rilasciabile.
# Esempio di pipeline GitHub Actions per trunk-based
name: CI
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- run: npm ci
- run: npm run lint
- run: npm test
- run: npm run buildCome migrare da Gitflow a trunk-based development senza fermare la produzione?
La migrazione non si fa in un giorno. Noi consigliamo un percorso graduale che minimizza i rischi e permette al team di adattarsi.
Passo 1 — Congela develop e lavora su main
Il primo passo è eliminare il branch develop. Tutti i branch feature ora partono da main. Questo è un cambio di mentalità più che tecnico: main diventa il punto di partenza e di arrivo di tutto.
Passo 2 — Riduci la durata dei branch feature
Imponi un limite di due giorni per la vita di un branch feature. Se una funzionalità richiede più tempo, va spezzata in sotto-attività più piccole. Puoi usare strumenti come GitHub Actions o Husky per bloccare i branch troppo vecchi.
Sponsored Protocol
# Comando per trovare branch feature più vecchi di 2 giorni
git branch --no-merged main --format='%(refname:short) %(committerdate:relative)' | grep 'days ago'Passo 3 — Implementa i feature flag
Prima di eliminare i branch di lunga durata, assicurati di avere un sistema di feature flag. Questo dà al team la sicurezza di integrare codice incompleto senza paura di rompere la produzione.
Passo 4 — Automatizza i test e il deploy
Investi nella pipeline CI/CD. Se non hai test automatici, il trunk-based development è rischioso. Inizia con test unitari per le parti critiche, poi aggiungi test di integrazione. L'obiettivo è avere una suite che gira in meno di 10 minuti e che dà fiducia al team.
Cosa fare adesso
Non serve una riunione di due ore per decidere. Ecco le azioni immediate che puoi fare oggi.
1. Analizza la tua frequenza di rilascio. Se fai deploy meno di una volta a settimana, Gitflow può ancora andare bene. Se vuoi arrivare a rilasci giornalieri o continui, il trunk-based è la strada.
2. Controlla la durata media dei tuoi branch feature. Apri il tuo repository e guarda i branch. Quanti hanno più di una settimana? Quelli sono il tuo problema.
3. Inizia a usare i feature flag. Anche se resti su Gitflow, i feature flag ti daranno flessibilità e ridurranno la paura del merge.
4. Misura i conflitti. Ogni conflitto è un costo. Se ne risolvi più di uno a settimana, la tua strategia di branching sta erodendo il tuo margine. Per approfondire la gestione dei conflitti, leggi la nostra guida su Git per sviluppatori.
La scelta tra Gitflow e trunk-based development non è un dettaglio tecnico: è una decisione che impatta la velocità con cui porti valore ai clienti. Scegli in base al tuo contesto, non alla moda. E se hai dubbi, parlane con chi lavora su questi temi ogni giorno.
