# Cos'è il trunk based development: una guida pratica
URL: https://whatshouldibuildnext.com/it/journal/cos-e-il-trunk-based-development
Type: blog
Locale: it
Published: 2026-10-24
Updated: 2026-10-26
---
> Il trunk based development è un modello in cui tutti uniscono piccole modifiche su un unico ramo almeno una volta al giorno. Ecco cosa serve per provarlo senza rompere main.
Cos'è il trunk based development? È un modello di branching in cui tutti uniscono piccole modifiche in un unico ramo condiviso, di solito chiamato main o trunk, almeno una volta al giorno. I rami, se li usi, vivono per ore, non per settimane. Il lavoro non finito viene rilasciato nascosto dietro un feature flag, così il trunk resta pronto al rilascio a ogni commit. Tutto qui, ed è meno esotico di quanto suggerisca il nome.
Ecco la scena che rende l'idea. Apri un progetto laterale che hai lasciato tre settimane fa. Il ramo della funzionalità è indietro di 41 commit rispetto a main, due file hanno conflitti e quello che stavi costruendo non combacia più con il codice intorno. Il trunk based development è l'abitudine che evita questa scena.
## Cosa significa davvero trunk based development
Il sito di riferimento [trunkbaseddevelopment.com](https://trunkbaseddevelopment.com/) lo definisce come un modello di controllo di versione in cui gli sviluppatori collaborano su un unico ramo condiviso ed evitano altri rami di sviluppo a lunga vita. I commit diretti sul trunk vanno bene per team molto piccoli. Anche le pull request vanno bene, purché i rami di funzionalità restino brevi e nascano dal lavoro di una sola postazione.
Tre regole portano gran parte del peso.
-
Unisci sul trunk almeno ogni 24 ore.
-
Tieni il trunk verde: una build rotta su main è la priorità assoluta per tutti.
-
Nascondi il lavoro incompleto con i feature flag invece di tenerlo su un ramo laterale.
Nota cosa manca. Non c'è un ramo develop, non c'è un lungo ramo di rilascio per ogni funzionalità, non c'è una fase finale di integrazione in cui tutti scoprono che il proprio codice non si incastra con quello degli altri. Con i vecchi modelli il dolore si accumula e poi arriva tutto in una volta.
## Perché batte i rami a lunga vita per la maggior parte dei piccoli team
Un ramo a lunga vita è un prestito. Ogni giorno che resta aperto si allontana un po' di più da main, e gli interessi arrivano sotto forma di conflitti di merge, ipotesi superate e review che nessuno riesce a chiudere perché il diff tocca 60 file.
[La pagina di DORA sul trunk based development](https://dora.dev/capabilities/trunk-based-development/) lega tre pratiche a una migliore velocità di consegna, stabilità e disponibilità, sulla base dei dati del suo State of DevOps. Tieni al massimo tre rami attivi nel repository. Unisci sul trunk almeno una volta al giorno. Evita code freeze e fasi di integrazione. Sono obiettivi concreti e misurabili, cosa rara in questo settore.
Per un dev solo o un team di tre persone l'argomento è ancora più semplice. Le piccole unioni sono facili da revisionare, facili da annullare e facili da capire sei mesi dopo, quando stai leggendo `git blame` alle 22 cercando di capire cosa stava pensando la te di allora.
Tre motivi per farlo, uno per non farlo. I motivi: diff più piccoli, feedback più rapido dalla CI e un main che puoi rilasciare anche di venerdì senza sudare. Il motivo per non farlo: se i test sono scarsi, unire ogni giorno diffonde i guasti più in fretta. Ci arriviamo più avanti.
## Rami brevi o commit diretti sul main?
Entrambi rientrano nel trunk based development. La differenza sta in quanta sicurezza vuoi prima che il codice entri.
Committare direttamente sul main funziona quando lavori da solo o in coppia, la build locale finisce in meno di un minuto e ti fidi dei tuoi test. È il ciclo più veloce che esista. La maggior parte dei builder solisti lo fa già senza chiamarlo così.
Rami brevi con pull request hanno senso quando si unisce una seconda o una terza persona, oppure quando vuoi che la CI giri su un checkout pulito prima del merge. La disciplina sta tutta nella parola brevi. Un ramo che sopravvive al giorno dopo sta già scivolando verso il modello che stai cercando di lasciare.
Una routine pratica che regge:
-
Fai il pull di main e crea un ramo con un nome che dica cosa cambia.
-
Fai la modifica più piccola che faccia avanzare le cose, ed esegui la build completa in locale.
-
Apri la PR, lascia girare la CI, unisci lo stesso giorno.
-
Elimina il ramo. Non lasciarli accumulare.
Se una modifica non si può chiudere in un giorno, la risposta non è un ramo più lungo. È tagliare la modifica più sottile.
## Come rilasciare lavoro incompleto senza rompere il main?
È la domanda che blocca la maggior parte delle persone. Se unisci ogni giorno, unirai codice per funzionalità che non esistono ancora. Due tecniche risolvono il problema.
La prima è il feature flag. Il nuovo percorso di codice viene unito ma spento, così gli utenti non lo vedono mai. Un flag può essere semplice come un booleano in una variabile d'ambiente:
`const showNewCheckout = process.env.FEATURE_NEW_CHECKOUT === "true";
export function Checkout() {
return showNewCheckout ? : ;
}`Per un progetto laterale basta questo. Quando ti servono targeting, rilasci graduali o un kill switch senza un nuovo deploy, un servizio gestito si guadagna il suo posto.
La seconda tecnica è il branch by abstraction, per cambiamenti più grossi come la sostituzione di un client di database o di un provider di pagamento. Metti un'interfaccia davanti all'implementazione vecchia, costruisci la nuova dietro la stessa interfaccia, sposta i chiamanti un pezzo alla volta, poi elimina la vecchia. Ogni passo è una piccola unione sul trunk e niente resta su un ramo lungo.
Un'avvertenza onesta sui flag: sono debito. Un flag che resta nel codice per un anno è un ramo travestito. Dai a ogni flag un responsabile e una data di rimozione, ed eliminalo quando la funzionalità è completamente rilasciata.
## Di cosa ha bisogno la tua CI prima di provarlo
Il trunk based development senza una rete di sicurezza è solo rottura veloce. Servono tre cose prima di impegnarti in un'abitudine di unione quotidiana.
-
Una build che giri a ogni push e finisca in minuti, non in mezz'ora.
-
Test che falliscano quando si rompe qualcosa di reale. I numeri di copertura contano meno del fatto che una modifica sbagliata venga intercettata.
-
Un modo rapido per tornare indietro: annullare il commit o spegnere il flag.
L'analisi statica è uno strato extra economico. Intercetta una classe di problemi, come bug evidenti, odori di sicurezza e codice duplicato, prima che un umano legga il diff.
Se sei l'unico revisore, uno strumento che segnala gli hotspot rischiosi aiuta ancora di più, perché nessun altro ti dirà che il file che tocchi sempre sta diventando un pasticcio.
Non serve una pipeline pesante già il primo giorno. Un singolo file di workflow che installa, lancia il lint, testa e rilascia main è un buon inizio. Funziona, non è ottimale, e vale la pena farlo comunque: è la prima versione che funziona, e puoi affinarla dopo.
## Release branch, hotfix e le cose che richiedono ancora attenzione
Il trunk based development non vieta i release branch. Alcuni team tagliano un ramo dal trunk poco prima di una release, lo induriscono, lo rilasciano e lo eliminano. Altri rilasciano direttamente dal trunk e correggono in avanti quando salta fuori un bug. Per un'app web rilasciata più volte a settimana, correggere in avanti è quasi sempre più semplice.
App mobile e tutto ciò che passa da una revisione lenta dello store sono un'altra storia. Lì potresti tenere un release branch breve per ogni versione, così puoi patchare ciò che è già nelle mani degli utenti. Anche così la regola vale: le correzioni arrivano prima sul trunk, poi vengono portate indietro con cherry-pick, mai al contrario.
Gli hotfix seguono la stessa logica. Correggi sul trunk, rilascia, fatto. Un ramo hotfix separato che non viene mai riunito al trunk è il modo in cui i team finiscono con due storie che divergono.
## Una prima settimana realistica
Primo giorno: controlla come il tuo repository gestisce i rami oggi. Elenca i rami aperti e annota l'età di ciascuno. Tutto ciò che è più vecchio di pochi giorni è candidato a essere unito o eliminato. Questo da solo spesso mostra dove si annida l'attrito.
Secondo giorno: aggiungi il meccanismo dei flag. Anche una variabile d'ambiente va bene. Scegli una funzionalità in corso, metti il suo punto d'ingresso dietro il flag, poi unisci quello che hai.
Dal terzo al quinto giorno: cambia l'abitudine. Taglia ogni attività in pezzi che possano atterrare in un giorno e unisci ogni pezzo quando la CI passa. I primi pezzi ti sembreranno troppo piccoli. Non lo sono. Un commit che aggiunge una colonna di database dormiente o una funzione non ancora usata è un'unità di progresso perfettamente valida, perché è sicura, revisionata e già integrata.
Alla fine della settimana saprai due cose: se i test sono abbastanza affidabili, e quali parti del codice resistono alle modifiche piccole. Entrambe sono utili, e nessuna delle due emerge mentre lavori su rami lunghi.
Non serve una dashboard per capirlo. Guarda quanto vivono i tuoi rami, quante volte il main è rosso e quanto tempo impiega una modifica dal primo commit alla produzione. Se l'età dei rami diminuisce e i deploy diventano noiosi, l'abitudine sta dando frutti.
Se vuoi numeri sugli effetti visibili agli utenti di ciò che rilasci dietro i flag, uno strumento di sperimentazione può collegare un rilascio a metriche reali invece che all'intuito.
Per chi lavora da solo, anche un semplice quaderno funziona. Annota ogni settimana il tempo che passa dall'unione al deploy, per un mese. La tendenza ti dice più di qualsiasi singola cifra.
## Conviene passare, o aspettare?
Passa se lavori da solo, in coppia o in un piccolo team con test di cui ti fidi a metà e una CI che puoi migliorare. Il costo di provare è una settimana di commit piccoli e un po' scomodi. Il costo di restare sui rami lunghi si paga in conflitti e review lente, e cresce a ogni collaboratore in più.
Aspetta se non hai affatto test automatici e nessun modo di tornare indietro. Sistema prima quello, perché unire ogni giorno su un trunk non testato sposta solo il dolore.
Non è un metodo perfetto. È un metodo praticabile. Scegli il prossimo piccolo cambiamento del tuo progetto attuale, uniscilo oggi e guarda come ti sembra. Qual è la fetta più piccola della funzionalità su cui stai lavorando che potresti rilasciare prima di stanotte?
## FAQ
### Cos'è il trunk based development in breve?
È un modello di branching in cui tutti uniscono piccole modifiche su un unico ramo condiviso almeno una volta al giorno, usando feature flag per nascondere il lavoro incompleto.
### Il trunk based development funziona anche se lavoro da solo?
Sì. Lavorando da soli si può committare direttamente sul main, purché la build sia veloce e i test siano affidabili.
### Quanti rami attivi dovrei avere al massimo?
DORA suggerisce al massimo tre rami attivi nel repository, con unioni al trunk almeno una volta al giorno.
### Serve per forza un servizio di feature flag?
No. Una variabile d'ambiente basta per un progetto piccolo. Un servizio gestito diventa utile quando servono rilasci graduali o un kill switch senza nuovo deploy.
### Qual è la differenza con GitFlow?
GitFlow usa un ramo develop e rami lunghi di funzionalità o di rilascio. Il trunk based development tiene quasi tutto sul trunk, con rami brevi che vivono ore o al massimo un giorno.
### Il trunk based development si applica alle app mobile?
Sì, con un'eccezione: se la revisione dello store è lenta, può essere utile un release branch breve per ogni versione, con le correzioni che partono sempre dal trunk.