git-cheatsheet-ita/docs/05-driessen-branching-model-gitflow.md

Driessen Branching Model

Il Driessen branching model, noto come Git Flow, definisce una struttura di branch chiara, utile per team e rilasci.

Branch principali

1. master

   • Contiene il codice in produzione
   • Ogni commit su master corrisponde, idealmente, a una versione rilasciata

2. development

   • Branch di integrazione per lo sviluppo
   • Qui confluiscono le feature completate
   • Da development partono i rilasci

---

Branch di supporto

1. Feature branch

• Nome: feature/<nome-breve>
• Partono da: development
• Ritornano in: development

Esempio:

git checkout development
git pull origin development

git checkout -b feature/nuovo-report
# ... sviluppo, commit, push ...
git push -u origin feature/nuovo-report

# alla fine, MR/PR verso development

Usi tipici: nuove funzionalità, modifiche non banali.

---

2. Release branch

• Nome: release/<versione>
• Partono da: development
• Ritornano in: prima development e poi dopo master

Esempio:

git checkout development
git pull origin development

git checkout -b release/1.2.0
# bugfix minori, aggiornamento versioni, changelog, ecc.
git push -u origin release/1.2.0

Alla fine:

1. Merge in development per allineamento
2. Merge in master (rilascio produzione)
3. Tag della versione (es. v1.2.0)

---

3. Hotfix branch

• Nome: hotfix/<descrizione-breve>
• Partono da: main
• Ritornano in: prima master e poi dopo development

Usati per bug urgenti in produzione.
Visto che la branch development potrebbe già essere più avanti di master, in questo caso è necessario operare direttamente su quest'ultima, e poi portare i cambiamenti sul ramo dev.

Esempio:

git checkout master
git pull origin master

git checkout -b hotfix/fix-crash-login
# ... correggi bug, commit, test ...
git push -u origin hotfix/fix-crash-login

Alla chiusura:

1. Merge in master (nuova patch in produzione)
2. Tag (es. v1.2.1)
3. Merge in develop (per non perdere il fix)

---

Mini workflow Git Flow tipico a Meridiana

1. Nuova feature

   git checkout development
   git pull origin development
   git checkout -b feature/nuova-funzionalita
   # sviluppo, commit, push...
   git push -u origin feature/nuova-funzionalita
   # apri MR verso development
   

2. Preparazione release

   git checkout development
   git pull origin development
   git checkout -b release/1.3.0
   # sistemazione dettagli di rilascio
   git push -u origin release/1.3.0
   # MR verso: **1. development**, **2. master** (o merge manuale)
   

3. Hotfix urgente

   git checkout master
   git pull origin master
   git checkout -b hotfix/fix-bug-critico
   # fix, commit, push
   git push -u origin hotfix/fix-bug-critico
   # MR verso: **1. master**, **2. development**
   

---

Note

• master deve essere sempre stabile
• Lo sviluppo ordinario avviene su development e sulle feature/*
• I rilasci vengono preparati su release/*
• I bug urgenti in produzione usano hotfix/*

Questo modello aiuta a:

• Separare chiaramente sviluppo, test e produzione
• Ridurre i conflitti su master
• Avere una storia più pulita per rilasci e hotfix