Aggiungi 'docs/05-driessen-branching-model-gitflow.md'

2025-12-05 10:17:28 +01:00
parent d3d841afc1
commit ba772e914c
1 changed files with 146 additions and 0 deletions
@@ -0,0 +1,146 @@
+<!-- File: 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:
+
+```bash
+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:
+
+```bash
+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
+1. Merge in `master` (rilascio produzione)
+2. 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:
+
+```bash
+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**
+
+   ```bash
+   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**
+
+   ```bash
+   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**
+
+   ```bash
+   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