145 lines
3.3 KiB
Markdown
145 lines
3.3 KiB
Markdown
<!-- 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 |