From ba772e914c5d44f24bb5824ebd14f83aa40ccb71 Mon Sep 17 00:00:00 2001 From: Giuseppe Rocco Date: Fri, 5 Dec 2025 10:17:28 +0100 Subject: [PATCH] Aggiungi 'docs/05-driessen-branching-model-gitflow.md' --- docs/05-driessen-branching-model-gitflow.md | 146 ++++++++++++++++++++ 1 file changed, 146 insertions(+) create mode 100644 docs/05-driessen-branching-model-gitflow.md diff --git a/docs/05-driessen-branching-model-gitflow.md b/docs/05-driessen-branching-model-gitflow.md new file mode 100644 index 0000000..b40de3a --- /dev/null +++ b/docs/05-driessen-branching-model-gitflow.md @@ -0,0 +1,146 @@ + + +# 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/` +- 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/` +* 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/` +* 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 \ No newline at end of file