Sviluppo trunk-based

Panoramica

Lo sviluppo trunk-based è un workflow in cui ogni sviluppatore integra in un unico branch condiviso — il trunk (di solito main) — almeno una volta al giorno. I branch, se utilizzati, sono piccoli e vivono per ore, non settimane. È il workflow alla base della vera integrazione continua ed è preferito dai team che rilasciano frequentemente.

L'idea centrale

Più il tuo codice si allontana da quello degli altri, più l'integrazione diventa difficile. Il costo di un merge cresce con la dimensione della divergenza: un branch che è vissuto due settimane accumula più conflitti, e quei conflitti sono più difficili da analizzare perché nel frattempo sono cambiate molte cose da entrambe le parti.

Lo sviluppo trunk-based affronta direttamente questo problema mantenendo il divario ridotto. Si integra nel trunk costantemente — almeno una volta al giorno — così qualsiasi conflitto è piccolo e viene rilevato mentre la modifica è ancora fresca in mente. Non esiste un branch develop a lunga durata né merge esplosivi. Il trunk è sempre in uno stato rilasciabile.

Esistono due stili comuni:

• Commit diretti sul trunk. I team piccoli eseguono commit direttamente su main, affidandosi a controlli pre-push e revisioni in coppia. Questa è la forma più pura.
• Branch a vita breve. I team più grandi aprono un branch per ogni modifica, aprono una pull request e fanno il merge entro un giorno o due. Il branch esiste solo il tempo necessario per eseguire la CI e ottenere una revisione rapida.

Un tipico ciclo con branch a vita breve si presenta così:

git switch main          # start from the trunk
git pull                 # get everyone else's latest work
git switch -c quick-fix  # tiny, focused branch
# ...a few hours of work...
git switch main
git pull                 # pull again — others have merged since you branched
git merge quick-fix      # fast, because divergence is small
git push                 # back on the trunk within the same day

Il git pull ripetuto è intenzionale: eseguire il pull prima del merge mantiene il branch vicino al trunk, così il merge rimane banale. Se si preferisce una cronologia lineare, alcuni team eseguono il rebase del branch a vita breve su main invece di fare il merge. Consulta il workflow feature branch per i dettagli sulla meccanica di branch e pull request.

Feature flag: rilasciare lavoro incompiuto in sicurezza

Se tutti fanno il merge nel trunk ogni giorno, come si gestisce una funzionalità che richiede due settimane? Non si può tenere un branch attivo così a lungo senza vanificare lo scopo. La risposta è un feature flag — un interruttore runtime che decide se il nuovo codice viene effettivamente eseguito. Si fa il merge del codice incompleto, ma lo si mantiene disattivato:

const featureFlags = { newCheckout: false };

function checkout() {
  if (featureFlags.newCheckout) {
    return "new checkout";
  }
  return "old checkout";
}

console.log(checkout()); // old checkout — flag is off in production

Il nuovo codice raggiunge la produzione nascosto dietro il flag. Quando è pronto, si imposta newCheckout su true — senza necessità di un nuovo deploy. Questo disaccoppia il deploy del codice dal rilascio di una funzionalità, permettendo al lavoro incompiuto di vivere in sicurezza sul trunk.

Alcune regole pratiche evitano che i flag diventino un disordine:

• Disattivato per default. Il nuovo codice è nascosto finché non lo si attiva deliberatamente, spesso prima per gli utenti interni.
• Tratta i flag come temporanei. Una volta che una funzionalità è completamente lanciata, rimuovi il flag e il ramo else inattivo — i flag obsoleti si accumulano rapidamente e rendono il codice difficile da leggere.
• Testa entrambi i percorsi. La CI deve verificare il codice con il flag attivo e disattivato, poiché entrambi vengono inviati in produzione.

Cosa richiede

Lo sviluppo trunk-based è veloce, ma non è approssimativo — funziona solo con pratiche di supporto solide:

• CI robusta: ogni push esegue una suite di test automatizzati, perché un trunk rotto blocca l'intero team.
• Commit piccoli e frequenti: le modifiche grandi vengono suddivise in passi incrementali sicuri.
• Feature flag per tutto ciò che non può essere completato in un singolo branch a vita breve.
• Revisione del codice rapida, spesso tramite pull request piccole che vengono integrate entro poche ore.

Se la revisione richiede giorni, i branch vivono per giorni e non si sta più facendo sviluppo trunk-based. Le pratiche di supporto non sono opzionali — sono ciò che rende la velocità sicura.

Rilasciare dal trunk

Poiché il trunk è sempre rilasciabile, i rilasci sono semplici. Due pattern dominano:

• Rilascio dalla punta. Distribuisci main direttamente, con la frequenza che preferisci. Contrassegna ogni rilascio con un tag per identificare esattamente cosa è stato consegnato:

  git switch main
  git pull
  git tag -a v1.4.0 -m "Release 1.4.0"
  git push origin v1.4.0

  Copia

• Crea un branch di rilascio. Per i prodotti che distribuiscono rilasci versionati, crea un branch di rilascio a vita breve dal trunk, stabilizzalo e taggalo da lì. Le correzioni vengono apportate prima sul trunk e poi cherry-picked sul branch di rilascio — mai il contrario, così il trunk rimane la fonte di verità.

Entrambi mantengono il trunk integro: è sempre il codice più recente e valido, e i rilasci sono istantanee prelevate da esso.

Trunk-based vs Gitflow

Gitflow è ottimizzato per rilasci controllati e versionati con molti tipi di branch. Lo sviluppo trunk-based è ottimizzato per la velocità e il rilascio continuo con essenzialmente un solo branch. Se distribuisci più volte al giorno, il trunk-based è adatto; se distribuisci rilasci versionati secondo un calendario, la struttura di Gitflow potrebbe servirti meglio.

Quando usarlo

Opta per lo sviluppo trunk-based quando distribuisci frequentemente, hai test automatizzati affidabili e puoi mantenere la revisione del codice rapida. Premia i team che privilegiano cicli di feedback brevi rispetto a processi pesanti. Se i tuoi test sono instabili, la revisione è lenta o devi raggruppare il lavoro in rilasci programmati, il workflow feature branch o Gitflow saranno meno dolorosi. Per una panoramica di tutti i modelli comuni, consulta la panoramica dei workflow Git.

Pratica