Scegliere una Strategia di Branching

Il trunk-based development porta il principio "i branch dovrebbero essere di breve durata" alla sua logica conclusione: i branch vivono ore, non giorni. Gli ingegneri inviano piccole modifiche incrementali al main più volte al giorno, utilizzando feature flag per nascondere il lavoro incompleto agli utenti.

I vantaggi sono reali. I problemi di integrazione emergono immediatamente perché i branch non si allontanano mai troppo dal main. Le esecuzioni CI sono veloci perché il diff è piccolo. Non c'è un "giorno di merge" perché il merge è continuo. I team che praticano il trunk-based development riportano frequenze di deployment 4–8× superiori rispetto ai team che utilizzano branch di lunga durata.

Anche i requisiti sono reali. Il trunk-based development richiede un'eccellente CI (i test devono essere veloci e affidabili), un'infrastruttura di feature flag robusta (devi rilasciare codice incompleto in sicurezza) e alta fiducia tra gli ingegneri (nessun gate di review significa che l'autore si assume la piena responsabilità). Per un team di 4 persone con una CI solida e una codebase condivisa, è spesso il modo più veloce di lavorare. Per un team di 30 persone con una copertura di test discontinua, è una ricetta per un branch main rotto.

Questo è GitHub Flow portato un passo oltre — meno branch, durate più brevi, maggiore affidamento sui flag rispetto all'isolamento.

GitHub Flow è l'impostazione predefinita giusta per la maggior parte dei team, e vale la pena capire perché. L'intero modello si adatta a tre regole: main è sempre deployabile, ogni modifica avviene su un branch di breve durata e i branch si uniscono al main tramite PR revisionate. Tutto qui.

Non c'è un branch develop, nessun branch release, nessun branch hotfix. Un branch per modifica, una PR per branch, un merge al main. Quando main riceve un nuovo merge, puoi deployarlo — manualmente, automaticamente o secondo una pianificazione. La semplicità è la caratteristica.

GitHub Flow funziona perché corrisponde al modo in cui la maggior parte dei team di prodotto effettivamente rilascia: continuamente, in piccoli incrementi, senza il sovraccarico di coordinare release train. Un feature branch vive per un giorno o due, viene revisionato, si unisce e viene rilasciato. Se rompe qualcosa, fai il revert e correggi. Il ciclo di feedback è stretto.

Dove GitHub Flow fatica è quando devi mantenere più versioni di produzione simultaneamente (rilasci la v2.3 ma devi patchare la v2.1 per un cliente), o quando il tuo processo di deploy è lento e costoso (rendendo "fai semplicemente il revert" irrealistico). Questi scenari richiedono un modello di branching più strutturato — ma sono l'eccezione, non la regola.

GitFlow è stato progettato per un mondo in cui il software veniva rilasciato su CD — release versionate, lunghi cicli di QA, più versioni supportate sul campo. Se questo è il tuo mondo (app desktop, sistemi embedded, software enterprise con supporto contrattuale delle versioni), la struttura di GitFlow giustifica la sua complessità.

Il modello aggiunge diversi branch di lunga durata: develop (integrazione), release/* (stabilizzazione), hotfix/* (patch di emergenza alla produzione) e main (stato di produzione). Le feature si diramano da develop, le release si biforcano da develop quando una versione è "feature-complete", e gli hotfix si diramano direttamente da main.

Per i team che deployano un'applicazione web — che è la maggior parte dei team che leggono questo corso — GitFlow è quasi certamente eccessivo. Il branch develop aggiunge un livello di indirezione tra il tuo lavoro e la produzione senza un beneficio proporzionale. I branch di release hanno senso solo se hai un gate QA formale tra "codice completo" e "rilasciato". I branch hotfix sono inutili quando deployare una correzione richiede minuti, non settimane.

GitFlow non è sbagliato. È progettato per un contesto specifico. Se non hai quel contesto (più versioni supportate, deploy lenti, gate di release formali), stai pagando la tassa della complessità senza il beneficio. Inizia con GitHub Flow. Puoi sempre aggiungere struttura in seguito se la situazione lo richiede — ma raramente ne avrai bisogno.