SC-4: Strategia di Branching

Descrizione

Una strategia di branching consistente facilita la collaborazione, riduce i conflitti di merge e supporta rilasci frequenti. I team DOVREBBERO (SHOULD) seguire un modello di branching semplice e prevedibile.

Guida

Modello di branching raccomandato

I team DOVREBBERO (SHOULD) seguire un modello di branching in stile GitHub Flow:

Il branch main (o master) è l’unico branch a lunga durata e rappresenta sempre codice deployable
Per ogni nuova feature o fix, creare un branch dal main
Effettuare commit regolarmente sul branch di feature
Aprire una pull request quando pronto per la review
Dopo approvazione e superamento dei check, fare merge in main
Deploy del main in produzione

Durata dei branch

I branch di feature DEVONO (MUST) essere a breve durata:

Idealmente: Ore o giorni
Massimo: Due settimane

Branch a lunga durata portano a:

Conflitti di merge complessi
Divergenza dal codice principale
Difficoltà di review
Ritardi nell’integrazione

Naming convention dei branch

I nomi dei branch DOVREBBERO (SHOULD) utilizzare un prefisso per indicare lo scopo:

Prefisso	Scopo	Esempio
`feature/`	Modifiche funzionali	`feature/user-authentication`
`bugfix/`	Correzione di difetti	`bugfix/login-error-handling`
`spike/`	Lavoro sperimentale (non merged)	`spike/graphql-evaluation`
`hotfix/`	Correzioni urgenti per la produzione	`hotfix/security-patch`

Alternative considerate

Trunk-Based Development: Simile a GitHub Flow ma con commit ancora più frequenti direttamente su main (con feature flag per funzionalità incomplete)

GitFlow: Modello più complesso con branch multipli a lunga durata (main, develop, release/*, hotfix/*). Raccomandato solo per progetti con cicli di release molto strutturati.

Misurazione

Stato	Criteri
🟢 VERDE	Branch short-lived, naming chiaro e consistente, strategia documentata
🟡 AMBRA	Pratiche miste, alcuni branch a lunga durata, naming inconsistente
🔴 ROSSO	Branch a lunga durata o non gestiti, nessuna strategia definita