Merge Requests¶

Code review systematique, conventions, approbations et CI gates — le merge request comme point de contrôle central.

Pourquoi des merge requests¶

Un merge request (MR) — ou pull request (PR) sur GitHub — est une demande formelle d'intégrer du code dans une branche cible. Ce n'est pas juste un mécanisme technique : c'est le point de convergence entre qualité, collaboration et traçabilité.

Sans MR :

• le code entre dans main sans aucune vérification humaine
• les bugs sont détectés en production au lieu de la review
• il n'y a aucune trace de pourquoi un changement a été accepte

Cycle de vie d'une merge request¶

graph LR
    A["Creer la branche"] --> B["Developper + committer"]
    B --> C["Ouvrir la MR<br/>(draft)"]
    C --> D["CI passe ?"]
    D -->|"non"| B
    D -->|"oui"| E["Review"]
    E -->|"changements demandes"| B
    E -->|"approuvee"| F["Merge"]
    F --> G["Supprimer la branche"]

1. Branche et développement¶

La branche suit une convention de nommage cohérente avec le workflow :

feature/42-ajouter-validation-email
fix/108-timeout-export-csv
chore/upgrade-dependencies

2. Ouverture en draft¶

Ouvrez la MR des le premier commit, en mode draft. Cela permet :

• à la CI de tourner des le début
• aux collegues de voir le travail en cours
• de commencer une discussion avant que le code soit "fini"

3. Description et template¶

Une bonne description de MR contient :

Code review¶

Les objectifs de la review¶

Ce que la review n'est PAS¶

• Un gatekeeping pour montrer qu'on sait mieux
• Un lieu pour debattre du style (c'est le job du formatter)
• Un blocage : si la MR est globalement bonne, approuvez avec des suggestions non-bloquantes

Bonnes pratiques¶

• Taille : visez des MR de moins de 400 lignes de changement. Au-delà, la qualité de la review chute drastiquement
• Temps de réponse : répondre dans les 4 heures — une MR qui attend 3 jours est une MR qui généré des conflits
• Tone : poser des questions ("est-ce que ce cas est géré ?") plutôt que donner des ordres ("change ca")

Approbations¶

Règles d'approbation¶

CODEOWNERS¶

# .github/CODEOWNERS ou CODEOWNERS
# Syntaxe : pattern   owners

/src/auth/          @security-team
/infra/             @platform-team
*.sql               @dba-team
package.json        @frontend-lead

Les fichiers matching sont automatiquement assignes aux reviewers désignés.

CI gates¶

La CI doit valider la MR avant que le merge soit possible. C'est le filet de sécurité automatique.

graph TD
    A["MR ouverte"] --> B["Pipeline CI"]
    B --> C{"Tests"}
    B --> D{"Lint"}
    B --> E{"Build"}
    C -->|"pass"| F["Status check OK"]
    D -->|"pass"| F
    E -->|"pass"| F
    C -->|"fail"| G["Merge bloque"]
    D -->|"fail"| G
    E -->|"fail"| G
    F --> H{"Approbations"}
    H -->|"suffisantes"| I["Merge autorise"]
    H -->|"insuffisantes"| J["Merge bloque"]

Configurer les branch protections¶

Sur la branche main, activez :

• Require status checks : les pipelines CI doivent passer
• Require approvals : au moins N approbations
• Require linear history : force squash ou rebase (optionnel)
• Block force push : personne ne peut forcer un push sur main
• Require signed commits : chaque commit doit être signe (voir Signature)

Conventions d'équipe¶

Labels¶

Milestones¶

Associez les MR a des milestones (sprints, releases) pour suivre la progression et générer des release notes automatiques.

Outils¶