Si tu bosses avec Git tous les jours, tu t’es sûrement déjà retrouvé face à ce dilemme :
“Est-ce que je fais juste un merge… ou est-ce qu’il faut une merge request ?”

Ces deux termes se ressemblent, mais ils n’ont pas du tout le même rôle :

• Le merge, c’est l’action rapide : une simple commande Git pour fusionner ton code localement
• La merge request, elle, va plus loin : c’est une étape clé du travail en équipe, où ton code est relu, testé, et validé avant d’arriver dans la branche stable

En gros, on pourrait dire que :

• merge = “j’intègre mon code direct”
• merge request = “je propose mon code à l’équipe pour validation”

Dans cet article, on va décortiquer ces deux notions, voir leurs différences concrètes et surtout comprendre dans quel cas utiliser l’un ou l’autre pour éviter les mauvaises surprises dans ton workflow Git.

Alors, le merge, c’est un peu le « raccourci » pour fusionner deux branches dans Git. Tu prends le travail d’une branche et tu l’intègres directement dans une autre. Rapide, efficace… mais sans filet.

git checkout dev
git merge TestMUAT2
git push origin dev

Ici, la branche TestMUAT2 est intégrée dans dev tout de suite.
Avantage : super rapide, pas besoin de passer par 10 étapes.
Inconvénient : personne pour relire ton code, donc attention aux bugs ou conflits surprises !

Bref, le merge, c’est pratique, mais à utiliser avec prudence quand on est en équipe.

Maintenant, parlons de la merge request, ou MR pour les intimes. C’est comme le merge, mais avec les copains derrière : tu proposes la fusion, et ton équipe peut jeter un œil avant que ça arrive dans la branche principale.

• Tes collègues peuvent relire et commenter le code.
• Les tests automatiques se lancent pour vérifier que tout va bien.
• Tu peux regrouper tes commits (squash) pour un historique propre et clair.

En gros, la MR, c’est le merge avec filet de sécurité, idéal pour travailler en équipe et éviter les mauvaises surprises.

Avec ce tableau, on voit clairement que le merge est rapide mais technique, tandis que la merge request apporte sécurité et collaboration.

Pour illustrer la différence entre merge et merge request, voici un workflow concret, détaillé et structuré pour un projet GitLab professionnel :

1. 1️⃣ Créer une branche à partir de RC :
   Cette étape permet de partir d’une branche stable pour préparer une modification ou correction.

   
   git checkout RC
   git checkout -b TestMUAT2
   git push origin TestMUAT2
         

   Ici, la branche TestMUAT2 est prête à recevoir les changements sans affecter la branche stable RC.


2. 2️⃣ Fusionner dev dans cette branche :
   On intègre les dernières modifications de dev pour éviter les conflits et s’assurer que tout est à jour.

   
   git merge dev
         

   Cela garantit que votre branche est compatible avec le travail en cours sur dev.


3. 3️⃣ Créer une Merge Request de TestMUAT2 vers dev :
   Cette étape active le processus collaboratif sur GitLab :

   • Relecture et validation par l’équipe.
   • Possibilité de commenter et discuter des changements.
   • Exécution automatique des pipelines CI/CD pour tests et vérifications.

   Cela garantit que le code est correct avant d’être intégré dans dev.
4. 4️⃣ Refaire une MR de dev vers RC :
   Une fois la MR précédente validée et fusionnée, on crée une nouvelle MR pour intégrer officiellement les changements dans la branche stable RC. Cela permet de maintenir RC toujours stable, testée et prête pour etre déployée en UAT.

En suivant ce workflow, chaque étape est validée, testée et documentée, réduisant les risques de bugs et conservant un historique Git clair et professionnel.

Le merge est une action purement technique, tandis que la merge request est un processus collaboratif qui garantit la qualité du code et la transparence dans une équipe. En pratique, sur GitLab, il est recommandé de toujours passer par des MR pour garder un historique propre et éviter les erreurs.