docs: norme merge squash (feature→develop→master)

Propagation depuis develop.

Co-authored-by: Julien Martin <julien.martin@ptits-pas.fr>

docs/24_DECISIONS-PROJET.md

@@ -1,7 +1,7 @@
 # 📋 Décisions Projet - P'titsPas
 
-**Version** : 1.2  
-**Date** : 16 Juin 2026  
+**Version** : 1.3  
+**Date** : 24 Septembre 2026  
 **Auteur** : Équipe PtitsPas
 
 ---
@@ -465,19 +465,34 @@ docs/
 
 ---
 
-### 26. Branches Git
+### 26. Branches Git + merge squash (norme)
 
-**Décision** : ✅ **Stratégie simple : master + feature branches**
+**Décision** : ✅ **`develop` + `master` + `feature/*`, merges en squash**
 
 **Justification** :
 - Simplicité (petite équipe)
-- Flexibilité
+- Historique lisible sur `develop` / `master` (1 commit = 1 ticket)
+- Déploiement prod uniquement depuis `master`
 
 **Branches** :
-- `master` : Production
-- `archive/*` : Archives (ex: maquette initiale)
-- `migration/*` : Migrations (ex: intégration YNOV)
-- `feature/*` : Nouvelles fonctionnalités
+- `master` : Production (déploiement auto)
+- `develop` : Intégration / recette
+- `feature/*` : Ticket en cours (depuis `develop`)
+- `archive/*`, `migration/*` : Archives / migrations ponctuelles
+
+**Flux (norme à partir de #169+)** :
+1. Branche `feature/N-…` depuis `develop`
+2. PR **feature → `develop`** : merge **squash** (`Do: squash` côté Gitea)
+3. Quand un lot est prêt : PR **`develop` → `master`** : merge **squash** également
+4. Message squash : `feat(#N): …` / `fix(#N): …` + `Closes #N` si applicable
+
+**Exception** : les merges `--no-ff` déjà poussés (ex. #167, #168) restent tels quels — pas de réécriture d’historique.
+
+**API Gitea** (rappel) :
+```http
+POST /repos/jmartin/petitspas/pulls/{index}/merge
+{"Do":"squash","MergeTitleField":"feat(#N): …","MergeMessageField":"Closes #N"}
+```
 
 ---