<!-- 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