Playbook Git

Statut	Actif — v1.1 — 2026-06-27
Priorité	P0
Obligatoire V1	Oui
Responsable	Sylvain
Voir aussi	Playbook CI · Playbook Release

Structure des branches

main        ← production, toujours stable
feature/*   ← nouvelles fonctionnalités
fix/*       ← corrections de bugs

La branche dev est optionnelle selon les projets. Quand elle existe, elle sert d'environnement de preview avant merge sur main.

Règles fondamentales

1. Aucune modification directe sur main — toujours passer par une branche et une PR.
2. Une PR = une unité de travail logique — pas d'accumulation de sujets sans rapport.
3. La CI doit être verte avant de merger — pas d'exception.
4. Une review est requise sur les projets en production (1 approbateur minimum).

Convention de nommage des branches

feature/<description-courte>
fix/<description-courte>

Exemples :

• feature/agenda-public
• feature/inscription-mairie
• fix/affichage-date-mobile
• fix/auth-token-refresh

Règles :

• Minuscules, mots séparés par des tirets
• Pas plus de 4-5 mots
• Numéro de ticket optionnel : feature/42-agenda

Convention des commits

Format : <Verbe> <sujet>

Ajoute la page agenda publique
Corrige l'affichage des dates sur mobile
Supprime le composant MapOld inutilisé
Refactore le service de messagerie
Met à jour les dépendances npm

Règles :

• Verbe au présent, 3e personne du singulier
• En français
• Majuscule initiale, pas de point final
• 72 caractères max sur la première ligne
• Corps optionnel séparé par une ligne vide si contexte nécessaire

Le format Conventional Commits (feat:, fix:) est autorisé mais non obligatoire.

Workflow quotidien

# 1. Partir d'un main à jour
git checkout main
git pull origin main

# 2. Créer la branche
git checkout -b feature/mon-sujet

# 3. Développer et committer
git add <fichiers>
git commit -m "Ajoute la fonctionnalité X"

# 4. Pousser et ouvrir la PR
git push -u origin feature/mon-sujet

Pull Requests

Titre : même convention que les commits.

Description minimale :

• Ce que fait la PR (1-2 phrases)
• Comment tester si ce n'est pas évident

Merge strategy : Squash and merge préféré (historique propre). Merge commit autorisé pour les releases.

Ne pas merger si :

• CI rouge
• Conversations non résolues
• Build cassé

Branch Protection (GitHub Settings)

La Branch Protection se configure manuellement dans Settings → Branches → Branch protection rules → Add rule.

Branch name pattern : main

Réglages à activer

Pull Requests

• ✅ Require a pull request before merging
• ✅ Require approvals : 1
• ✅ Dismiss stale pull request approvals when new commits are pushed
• ✅ Require review from Code Owners (@SylScat via .github/CODEOWNERS)
• ✅ Require conversation resolution before merging

Status Checks

• ✅ Require status checks to pass before merging
• ✅ Require branches to be up to date before merging

Checks à enregistrer par dépôt (voir procédure ci-dessous) :

Dépôt	Check
dmv-public	CI / Lint · Typecheck · Build
dmv-workspace	CI / Lint · Typecheck · Build
api	CI / Quality & Tests

Restrictions

• ✅ Do not allow bypassing the above settings (s'applique aussi aux admins)
• ✅ Block force pushes
• ✅ Block branch deletions

Réglages à ne pas activer pour l'instant

• ❌ Require signed commits — complexifie inutilement le workflow local
• ❌ Require linear history — non nécessaire avec squash and merge
• ❌ Merge queue — réservé aux équipes à fort volume de PR
• ❌ Restrict who can push to matching branches — géré via les rôles GitHub
• ❌ Lock branch — réservé aux branches archivées

Procédure d'enregistrement des status checks

Les checks GitHub Actions n'apparaissent dans le champ de recherche qu'après avoir été exécutés au moins une fois. Procédure :

1. Ouvrir une PR de test vers main (même triviale — ex: correction de typo)
2. Attendre la fin du workflow CI
3. Aller dans Settings → Branches → main → Edit
4. Dans "Require status checks to pass", cliquer "Add checks" et rechercher le check
5. Sélectionner CI / Lint · Typecheck · Build (frontends) ou CI / Quality & Tests (api)
6. Sauvegarder — la règle est immédiatement active