Merge Requests et code review
La Merge Request (MR) est le coeur du workflow collaboratif GitLab. Elle encapsule un ensemble de commits, les discussions de revue, les resultats des pipelines CI, les approbations et la politique de merge. C'est la porte d'entree vers la branche principale.
Cycle de vie d'une MR
Une MR passe par plusieurs etats : Draft (brouillon, non mergeable), Open (ouverte pour revue), Approved (validee par les approbateurs requis), Merged (fusionnee) ou Closed (fermee sans merge). Le statut Draft est signale par le prefixe "Draft:" dans le titre, empechant le merge accidentel.
Approbations
GitLab supporte un systeme d'approbation configurable :
- Nombre minimum d'approbateurs : N membres doivent approuver avant le merge
- Approbateurs specifiques : certains utilisateurs ou groupes doivent approuver
- Code Owners : fichier
CODEOWNERSa la racine du depot definit des proprietaires par chemin. Tout changement sur ces chemins requiert leur approbation. - Reset on push : les approbations sont annulees si de nouveaux commits sont pousses (option configurable)
Outils de revue
La revue de code dans GitLab se fait sur le diff inline ou dans le fichier entier. Les commentaires peuvent etre places sur une ligne specifique, une plage de lignes ou sur le fil de discussion general. Les threads de revue ont des statuts : ouvert ou resolu. La MR peut etre configuree pour n'etre mergeable que si tous les threads sont resolus.
Fonctionnalites notables :
- Suggestions : le relecteur peut proposer une modification de code directement depuis le diff, que l'auteur peut accepter en un clic
- Batch suggestions : regrouper plusieurs suggestions en un seul commit
- Reviewer assignment : assigner explicitement des relecteurs, distincts des assignees
Strategies de merge
GitLab supporte plusieurs strategies au merge :
- Merge commit : commit de merge explicite, historique complet
- Merge commit with semi-linear history : requiert un rebase prealable, mais cree quand meme un commit de merge
- Fast-forward : historique lineaire, pas de commit de merge — la branche doit etre a jour
- Squash and merge : tous les commits de la MR sont ecrases en un seul
Le choix de strategie impacte la lisibilite du git log et la facilite des bisections futures.
Merge Train (EE)
Le Merge Train resout le probleme des tests qui passent sur une branche mais echouent une fois mergee avec d'autres MR en cours. GitLab simule le merge dans l'ordre de file d'attente et lance la CI sur le resultat projete. Si un test echoue, la MR concernee est ejectee de la file. Disponible en Premium+.