Merge Request (MR) : qu'est-ce que c'est, comment le créer et le processus de révision

Qu'est-ce qu'un Merge Request (MR) ?

Merge Request (MR) — une demande d'intégration de modifications d'une branche Git à une autre, qui lance le processus de révision de code et de vérifications automatisées. Contrairement à la fusion directe via la console, le MR crée une procédure formelle : le développeur décrit les modifications, attribue des relecteurs, lance CI/CD et reçoit des retours avant l'application des modifications. C'est un élément clé de GitLab, mais le mécanisme équivalent dans GitHub s'appelle Pull Request (PR).

Selon GitLab Documentation, 2026, plus de 80 millions de Merge Requests sont créés dans GitLab chaque année. Chaque MR contient quatre composants principaux : une description avec le contexte des modifications, une liste de commits, la différence de code (diff) et une discussion (fil de discussion). Sans l'un de ces éléments, le MR est considéré comme incomplet.

Merge Request (MR) résout trois tâches : il empêche les modifications directes dans les branches protégées (main, develop), assure le contrôle qualité via la révision et préserve l'historique des discussions pour les futurs développeurs. Dans GitLab, le statut du MR est affiché dans l'interface avec des indicateurs de couleur : gris pour Draft, orange pour en attente, vert pour Approved, violet pour Merged et rouge pour Closed.

Terminologie : MR, PR et CR

Sur différentes plateformes Git, Merge Request est appelé différemment. GitLab utilise « Merge Request » (MR), GitHub utilise « Pull Request » (PR). L'analogie est Change Request (CR) dans Gerrit. Les trois désignent le même processus : une demande d'intégration de modifications par révision de code. Le choix du terme dépend uniquement de la plateforme utilisée dans le projet.

# Créer une branche avec des modifications
git checkout -b feature/add-auth
git commit -m "Add OAuth2 authentication flow"
git push origin feature/add-auth

# Vous pouvez créer un MR via l'interface GitLab/GitHub ou la CLI :
gh pr create --title "Add OAuth2 authentication flow" \
  --body "Implements OAuth2 with Google and Apple providers" \
  --reviewer "team-lead"

MR vs PR : la différence entre GitLab et GitHub

Merge Request dans GitLab et Pull Request dans GitHub sont des mécanismes fonctionnellement identiques avec des noms différents. La différence est due à l'histoire : GitLab s'est initialement positionné comme une alternative auto-hébergée à GitHub et a choisi le terme « merge request » pour le processus de fusion. GitHub, lancé plus tôt, a utilisé « pull request » — une demande pour « tirer » (pull) les modifications dans la branche principale.

Selon GitHub Docs, 2024, les deux outils supportent le même ensemble de fonctionnalités : description en Markdown, attribution de relecteurs, commentaires sur des lignes de code spécifiques, statuts de vérification et fusion automatique lorsque les conditions sont remplies. Les différences concernent l'interface et les capacités supplémentaires.

Comment créer un Merge Request : guide étape par étape

La création d'un Merge Request (MR) commence par la publication d'une branche avec des modifications dans le dépôt distant. Après le push vers GitLab ou GitHub, l'interface affiche un bouton « Create Merge Request » ou « Compare & Pull Request ». Le développeur remplit la description, spécifie la branche cible (généralement develop ou main), attribue des relecteurs et attache des étiquettes.

Selon GitLab Documentation, 2025, un MR standard contient un titre de 72 caractères maximum, une description avec modèle et un lien vers le ticket. La description doit répondre aux questions : ce qui a été fait, pourquoi, comment cela a été testé. GitLab supporte la fermeture automatique des tickets lors de la fusion via les mots-clés Closes, Fixes, Resolves.

# Exemple de modèle .gitlab/merge_request_templates/default.md
## What does this MR do?

[Brève description des changements : quoi et pourquoi]

## How to test

1. Exécuter ./gradlew test
2. Vérifier LoginActivity avec un jeton de test
3. S'assurer qu'il n'y a pas de régression dans AuthManager

## Related issues

Closes #142

Cycle de vie du MR : de Draft à Merged

Merge Request (MR) passe par cinq statuts dans GitLab. Le premier est Draft (brouillon), marqué par le préfixe « Draft: » dans le titre, qui bloque la fusion. Quand il est prêt, le développeur supprime Draft et le MR passe au statut Opened — la révision de code commence et le pipeline CI/CD démarre.

Selon GitLab Docs, 2024, dans le statut Opened, les relecteurs examinent le diff, laissent des commentaires et demandent des modifications via Resolve Threads. Lorsque tous les fils sont résolus et que CI/CD réussit, le développeur responsable définit Approve. Après cela, le MR peut être fusionné via le bouton Merge, ou on peut attendre la fusion automatique (Auto-merge).

GitLab supporte trois options de statut final : Merged (fusionné avec succès), Closed (fermé sans fusion, par exemple lors de l'abandon d'une fonctionnalité) et Reopened (réouverture après fermeture). Chaque statut est enregistré dans la chronologie d'activité du MR pour audit.

Statuts automatiques et déclencheurs

GitLab met automatiquement à jour le statut du Merge Request lors d'événements : le push de nouveaux commits réinitialise les Approvals, en cas de succès du pipeline CI le statut devient Pipeline passed, en cas d'échec — Pipeline failed (la fusion est bloquée). Auto-merge peut être configuré : le MR est automatiquement fusionné après un CI réussi et la réception de toutes les approbations requises.

• Draft — brouillon, CI s'exécute mais fusion bloquée
• Opened — prêt pour la révision, relecteurs attribués, pipeline actif
• Approved — nombre requis d'approbations reçu
• Merged — modifications fusionnées dans la branche cible
• Closed — fermé sans fusion

Règles de révision de code dans Merge Request

La révision de code dans Merge Request (MR) est une étape obligatoire dans la plupart des projets commerciaux. Selon l'étude SmartBear, 2023, la révision de code avec MR réduit le nombre de défauts de 30 à 60 % et accélère l'intégration des nouveaux développeurs. La règle principale est que chaque MR soit vérifié par au moins un, de préférence deux développeurs n'ayant pas participé à l'écriture du code.

La vérification du MR comprend cinq critères : exactitude logique, conformité au style de code, couverture de tests, sécurité et performances. Dans GitLab, les approbations requises (Required Approvals) peuvent être configurées — le nombre obligatoire d'approbations avant la fusion, par exemple 2 approbations pour main et 1 pour develop.

La discussion dans le MR se déroule dans des fils (Threads) — commentaires sur des lignes de code spécifiques. Chaque fil doit être résolu avant la fusion. Pour accélérer les révisions, il est recommandé de limiter la taille du MR : 200 à 400 lignes de modifications. Selon Google Research (2022), les MR de plus de 400 lignes sont révisés 30 % moins efficacement.

Pipeline CI/CD dans Merge Request

Lors de la création d'un Merge Request (MR), le pipeline CI/CD démarre automatiquement. Dans GitLab, cela se fait via le fichier .gitlab-ci.yml, dans GitHub via le workflow GitHub Actions. Le pipeline inclut la construction du projet, les tests unitaires, les linters, l'analyse statique (SAST) et la vérification de la couverture de code.

Selon GitLab Blog, 2024, le statut du pipeline est affiché directement dans le MR : coche verte (passed), croix rouge (failed) ou cercle jaune (running). Si le pipeline échoue, GitLab bloque le bouton Merge jusqu'à la correction. Dans les paramètres, « Merge when pipeline succeeds » peut être activé — fusion automatique après un pipeline réussi.

# .gitlab-ci.yml — exemple pour un projet Android
test:
  stage: test
  script:
    - ./gradlew ktlintCheck
    - ./gradlew testDebugUnitTest
  only:
    - merge_requests

build:
  stage: build
  script:
    - ./gradlew assembleDebug
  only:
    - merge_requests

Méthodes de fusion : Squash, Merge Commit, Fast-Forward

GitLab et GitHub proposent trois méthodes de fusion pour Merge Request. Le choix dépend de la politique de l'équipe et de la propreté souhaitée de l'historique. Merge Commit crée un commit de fusion séparé, préservant tout l'historique de la branche de fonctionnalité. Squash combine tous les commits de la branche en un seul commit sur la branche cible. Fast-Forward applique les commits linéairement sans commit de fusion.

Selon GitLab Docs, 2025, Squash est préférable pour les projets à forte densité de commits (20+ commits dans une branche de fonctionnalité). Fast-Forward est obligatoire pour le Trunk-Based Development. Merge Commit est utilisé dans Git Flow pour préserver la sémantique de branchement.

• Merge Commit — préserve l'historique, crée un commit de fusion, adapté à Git Flow
• Squash — combine tous les commits en un seul, historique propre, perd les commits intermédiaires
• Fast-Forward — historique linéaire sans commit de fusion, obligatoire en TBD

Meilleures pratiques : comment rédiger un bon MR

Un Merge Request (MR) de qualité réduit le temps de révision et le nombre d'erreurs. La première règle est qu'un MR résout une tâche. Si les modifications affectent plusieurs fonctionnalités non liées, elles doivent être divisées en MR séparés. Deuxièmement, le titre du MR doit être informatif : « Add OAuth2 authentication with Google provider » plutôt que « Fix stuff » ou « Update code ».

Selon Google Engineering Practices, 2024, un bon MR contient une description du contexte : pourquoi les modifications sont nécessaires, comment elles ont été testées et quels risques existent. La taille du MR ne doit pas dépasser 400 lignes de modifications. Si le volume est plus grand, la tâche doit être décomposée en sous-tâches. Pour la documentation et les tests, des exceptions sont acceptables mais avec explication.

Merge Request (MR) doit inclure des tests automatisés pour la nouvelle fonctionnalité. Dans GitLab, la politique Coverage Check peut être configurée — le MR est automatiquement bloqué si la couverture de code tombe en dessous d'un seuil (par exemple 80 %). Cela garantit que la nouvelle fonctionnalité ne réduit pas la qualité globale du projet.

• Un MR — une tâche : décomposez les modifications importantes en plusieurs petits MR
• Description avec modèle : utilisez .gitlab/merge_request_templates pour l'uniformité
• Taille jusqu'à 400 lignes : les gros MR sont révisés plus lentement et avec plus d'erreurs
• Tests obligatoires : les nouvelles fonctionnalités doivent être couvertes par des tests unitaires

Modèles de description MR

GitLab supporte les modèles de Merge Request via les fichiers .gitlab/merge_request_templates/. Le modèle comprend des sections : ce qui a été fait, comment tester, les tâches associées et une liste de contrôle. L'utilisation de modèles accélère la création de MR et garantit que les développeurs n'oublient pas d'inclure des informations importantes. Dans la description du MR, les tickets associés (Closes #N) doivent être spécifiés pour la fermeture automatique des tâches lors de la fusion.