14. Workflow e strategie di branching

Git non impone alcun workflow: nel tempo la community ha però individuato alcune pratiche consolidate. Il workflow incide anche su CI/CD e modalità di deploy del progetto.

14.1 Workflow centralizzato

Tutti i membri del team committano direttamente sul branch principale del repository remoto.

✅ Semplice, adatto a chi inizia; forza a mantenere la copia locale pulita e aggiornata.
❌ Funziona solo con team piccoli e comunicazione efficiente; richiede coordinamento sui rilasci; rischia di avere sul remote funzionalità non pronte o modifiche bloccate in locale.

14.2 Feature branching

Ogni feature o fix si sviluppa su un branch dedicato, riportato sul branch principale solo a lavoro completato (di solito via pull/merge request sulla piattaforma di hosting). Più sviluppatori possono contribuire allo stesso feature branch.

✅ Branch principale pulito finché la feature non è completa; condivisione anticipata del lavoro; lavoro parallelo.
❌ Più lunga è la vita del branch, più conflitti accumula rispetto al principale; non gestisce rilasci di più versioni incompatibili.

14.3 Trunk-based development

Sviluppo concorrente su un singolo branch principale, aggiornato molto frequentemente. Suggerimenti chiave:

funzioni incomplete si possono integrare sul principale, disattivate tramite feature flag;
branch usati solo se davvero necessari: feature branch brevi (chiusi in pochi giorni), branch di release solo per fix a versioni già rilasciate.
✅ Conflitti minimizzati grazie agli update frequenti; branch principale sempre pulito e orientato alla continuous delivery.
❌ Richiede tecniche aggiuntive (feature flag, CD) e un team con profonda conoscenza e ownership del progetto.

14.4 Approccio “forking”

Invece di un solo repository remoto, ogni contributore (o gruppo) ha un fork separato: tipico dei progetti open source, dove solo i maintainer scrivono sul repository principale. I fork si gestiscono con i remote multipli di Git (upstream/origin); GitHub e GitLab hanno costruito su questo modello le funzionalità di fork e pull request.

✅ Gestione semplice dei permessi anche con team grandi o collaboratori occasionali; possibile mantenere fork con modifiche mai integrate upstream.
❌ Richiede familiarità con l’uso di remoti multipli.

14.5 GitFlow

Uno dei primi workflow di grande impatto (2010), ottimizzato per progetti basati su release pianificate. Definisce tipi di branch dedicati:

Branch	Ruolo
`main`	history dei rilasci ufficiali
`develop`	integrazione delle feature
`feature/*`	nascono e si mergiano su `develop`
`release/*`	nascono da `develop`; i fix finali vengono mergiati sia su `main` che su `develop`; nel nome la versione rilasciata
`hotfix/*`	nascono da `main`; fix urgenti per versioni già rilasciate, mergiati su `main` e `develop`

✅ Ottimo per software a rilasci versionati, con canale dedicato agli hotfix.
❌ Onere notevole nella gestione dei nomi e del flusso di branch; non tratta le modalità di deploy; l’autore stesso (Vincent Driessen) ne ha ripreso e rivalutato l’uso a distanza di anni. Valutare bene le implicazioni prima di adottarlo.