Bonnes pratiques Git · 04

Merge requests
& revue

La merge request est le seul chemin vers les branches partagées. Elle sert à relire, à tester et à garder la trace des décisions.

04Étapes01Sujet par MR

Objectif

Des merge requests petites, compréhensibles et validées par la CI, relues rapidement et avec bienveillance.

1. Préparer sa branche

Avant d’ouvrir la merge request :

• la branche est à jour avec la cible : git fetch origin && git rebase origin/develop ;
• le projet compile et les tests passent en local (./mvnw verify, npm test, npm run lint) ;
• l’historique est propre : commits atomiques, messages au bon format, pas de commit « wip » (voir Git avancé) ;
• vous avez relu votre propre diff, comme le ferait un relecteur ;
• les tests et la documentation suivent le changement.

git fetch origin
git rebase origin/develop
git push --force-with-lease      # uniquement si la branche était déjà poussée

2. Ouvrir et décrire la merge request

• Titre au format des commits : feat(ordonnance): ajouter l'export PDF.
• Une MR = un sujet. Visez moins de 400 lignes modifiées : au-delà, la qualité de la revue chute.
• Brouillon (Draft) tant que le travail n’est pas prêt : la MR est visible, mais ne peut pas être fusionnée.
• Lien vers le ticket : Closes #23 ferme le ticket GitLab à la fusion, Refs: CMA-142 pour un ticket externe.

Modèle de description, à versionner dans .gitlab/merge_request_templates/Default.md pour qu’il soit proposé automatiquement :

## Contexte
Pourquoi ce changement ? Lien vers le ticket.

## Changements
- ...

## Comment tester
1. ...

## Captures d'écran
(pour les changements d'interface)

## Points d'attention
Migration de base, configuration à ajouter, impact sur d'autres applications...

Closes #

3. Relire une merge request

Ce que vérifie le relecteur

Axe	Questions
Fonctionnel	Le besoin du ticket est-il couvert ? Les cas limites sont-ils traités ?
Lisibilité	Le code se comprend-il sans explication orale ? Les noms sont-ils clairs ?
Tests	Les nouveaux comportements sont-ils testés ? La CI est-elle verte ?
Sécurité	Aucun secret, entrées validées, droits vérifiés côté serveur
Données	Migration de base réversible, pas de perte de données
Performance	Pas de requête dans une boucle, pas de chargement inutile
Documentation	README, configuration et Codex à jour si nécessaire

Le ton de la revue

• On commente le code, jamais la personne.
• On explique une demande de changement, et on propose une alternative concrète. La fonction Suggestion de GitLab permet de proposer directement la modification.
• Les questions sont légitimes : « pourquoi ce choix ? » est un bon commentaire.
• On distingue l’obligatoire du facultatif : préfixez par exemple nit: une remarque de détail non bloquante.
• On tient compte de l’expérience de l’auteur : une revue est aussi un moment de transmission.
• On répond vite : une MR qui attend plusieurs jours accumule des conflits. Visez une première revue dans la journée.

Côté auteur

• Répondez à chaque fil de discussion, puis laissez le relecteur le résoudre.
• Ajoutez les corrections dans de nouveaux commits pendant la revue, pour que le relecteur voie ce qui a changé. Regroupez-les avec --autosquash juste avant la fusion.

4. Fusionner

Conditions de fusion, configurées dans Paramètres › Merge requests :

• pipeline vert ;
• tous les fils de discussion résolus ;
• au moins une approbation, deux pour les MR vers main et vers les branches preprod et prod du dépôt GitOps ;
• branche à jour avec la cible (méthode Merge commit with semi-linear history).

Option	Quand l’utiliser
Commit de merge (par défaut)	Cas général : chaque fonctionnalité reste regroupée dans l’historique
Squash commits	Petite MR dont les commits intermédiaires n’apportent rien au lecteur
Supprimer la branche source	Toujours, pour les branches de travail

Les merge requests de promotion

Les MR develop → recette, recette → main, puis recette → preprod → prod dans le dépôt GitOps ne contiennent pas de nouveau code. Elles servent à valider le passage d’un environnement à l’autre :

• titre explicite : Promotion recette → main : version 1.5.0 ;
• liste des tickets inclus dans la description ;
• jamais de squash, pour conserver les commits d’origine ;
• validées par la personne responsable de la livraison.