Les Merge Requests sur GitLab : Collaborer et valider le code
C'est quoi une Merge Request et pourquoi l'utiliser ?
La Merge Request (ou MR) est sans doute la fonctionnalité la plus importante pour le travail en équipe sur GitLab. Une fois que vous avez fini de coder une fonctionnalité sur votre branche isolée, vous ne pouvez pas simplement l'injecter dans le code principal sans vérification. C'est ici qu'intervient la Merge Request.
Imaginez que la Merge Request est une relecture de code officielle. Vous dites à vos collègues : "J'ai terminé mon travail sur cette branche, voici les changements que je propose d'ajouter au projet principal. Pouvez-vous vérifier si tout est correct ?". Cela permet de discuter des modifications, de suggérer des améliorations et de s'assurer qu'aucun bug ne rentre dans la version stable du logiciel.
Information importante
Pour créer une Merge Request, vous devez impérativement avoir travaillé sur une branche différente de la branche principale (main). Si vous avez oublié comment faire, relisez le chapitre sur la création de branches.
Les étapes pour créer une Merge Request
Le processus se déroule sur l'interface web de GitLab et permet de documenter vos intentions avec précision avant la fusion finale.
Accéder à l'onglet dédié
Rendez-vous sur la page de votre projet. Dans le menu latéral de gauche, cliquez sur Code puis sur Merge Requests. Pour lancer une nouvelle demande, cliquez sur le bouton bleu New merge request.
"L'onglet Merge Requests centralise toutes les propositions de changements"
Sélectionner les branches source et cible
GitLab va vous demander de comparer deux univers distincts :
- Source branch : C'est la branche où vous avez écrit votre nouveau code.
- Target branch : C'est la branche de destination, généralement main.
"Choisissez bien votre branche de travail comme source et main comme cible"
Cliquez sur le bouton Compare branches and continue pour passer à la suite de la configuration de la MR.
Décrire et assigner le travail
Cette étape est cruciale pour que vos collègues comprennent l'objectif de vos modifications. Vous devez remplir plusieurs champs :
- Title : Donnez un nom explicite à votre modification. Vous pouvez cocher Mark as draft pour indiquer que votre travail est encore en cours et empêcher une fusion accidentelle.
- Description : Détaillez le contenu de vos changements. C'est l'endroit idéal pour lier un ticket (ex: "Closes #1") afin d'automatiser la clôture des tâches.
- Assignee : Désignez le responsable de la fusion. Le lien "Assign to me" permet de vous l'attribuer en un clic.
- Reviewer : Choisissez les collègues chargés de la revue de code. Leur validation est souvent requise avant toute intégration.
- Milestone & Labels : Liez votre demande à un jalon temporel ou ajoutez des étiquettes pour catégoriser vos modifications (ex: bug, feature).
- Merge can start : Cette option permet de définir si la fusion peut se faire à tout moment ou si elle doit attendre que certains critères (comme le passage des tests) soient remplis.
- Merge options : Deux réglages essentiels pour garder un projet propre :
- Delete source branch : Supprime automatiquement votre branche de travail après la fusion pour éviter d'encombrer le dépôt.
- Squash commits : Fusionne tous vos commits intermédiaires en un seul commit propre pour simplifier l'historique Git du projet.
Soumettre la demande
Une fois que tout est prêt, cliquez sur le bouton Submit merge request. Votre demande est maintenant publiée. Vos collègues peuvent voir les différences de code (diff), laisser des commentaires sur des lignes précises et finalement cliquer sur Merge pour intégrer officiellement votre travail.
"Une fois publiée, la MR devient un espace de discussion technique"
Conclusion
La Merge Request est le pilier de la qualité logicielle sur GitLab. Elle transforme l'écriture du code en un effort collectif, transparent et sécurisé. C'est le moment où les idées sont partagées et validées avant d'être déployées en production.
Pour rendre vos flux de travail encore plus professionnels, il est possible de lier automatiquement vos demandes aux tickets résolus. C'est ce qu'on appelle le référencement d'issues, et nous allons voir comment l'utiliser dans le chapitre suivant.
Espace commentaire
Écrire un commentaire
Vous devez être connecté pour poster un message !
16 commentaires
MRs, la base de toute CI/CD moderne, bien vu le rappel
Code review essentielle pour la qualité du code
Fusion sécurisée vers la branche main c'est la clé, zéro erreur
Super guide pour les Merge Requests, ultra pratique
C'est quoi une MR et pourquoi l'utiliser, enfin bien expliqué
Accéder à l'onglet dédié, direct au but, gain de temps
sélectionner les branches source et cible, attention cruciale, merci de l'insistance
décrire et assigner le travail, la doc de la mr, important pour le suivi
Plus de merges foireux en production, on valide avec ce guide
Flux de dev bien huilé grâce à ces pratiques
Merci pour ce rappel sur les Merge Requests
On avait des juniors qui ne voyaient pas l'intérêt. Votre explication sur pourquoi l'utiliser a tout clarifié pour eux, maintenant ils font des MRs propres
Les étapes pour créer une MR sont nickel
J'ai pu refaire la démo à l'équipe en me basant dessus. Ça accélère l'adoption des bonnes pratiques de code review et de fusion
La section sur décrire et assigner le travail est capitale
Souvent on bâcle cette partie. Ce guide m'a rappelé l'importance d'une bonne description pour la relecture et l'historique du projet. On a moins de questions sur le pourquoi des changements
sélectionner les branches source et cible, c'est le piège
On a déjà eu des merges sur la mauvaise branche. Ce point met bien en garde et évite les catastrophes en prod
Vraiment un bon topo pour la validation du code
Ça nous a permis d'affiner notre processus de code review. On a moins de bugs qui passent en main grâce à des MRs bien faites et bien relues
Soumettre la demande, la dernière étape pour un code propre, merci