Pull request
Une pull request, appelée merge request sur GitLab, est une proposition de fusionner les modifications d'une branche dans une autre, en général la branche principale. Elle affiche les différences ligne par ligne, rassemble les commentaires de relecture et lance des vérifications automatiques comme les tests et les linters. Les modifications n'atteignent la branche principale qu'une fois les règles de l'équipe respectées, par exemple une approbation et toutes les vérifications au vert.
Pourquoi c’est important pour un PM
La pull request est l'endroit où le code rencontre les exigences de qualité de l'équipe, et souvent celui où le PM peut essayer un changement dans un environnement de préversion avant sa mise en ligne. Le PM qui ouvre de petites pull requests (corrections de textes, documentation, prototypes) ou relit le travail d'un agent IA doit savoir ce qui en rend une facile à relire et sûre à fusionner.
Exemple
Une PM met à jour les e-mails d'onboarding dans une pull request intitulée « Raccourcir la séquence d'e-mails de bienvenue ». La description explique l'objectif, liste les trois e-mails modifiés et renvoie vers la préversion. Les tests passent, un développeur approuve et la modification est fusionnée dans la branche principale.
Points clés
- Une description utile explique le but, résume le changement, donne les étapes de test et nomme ce qui est volontairement laissé de côté.
- De petites pull requests ciblées sont relues plus vite et mieux que de grosses.
- Des règles de protection de branche peuvent exiger relectures et vérifications réussies avant toute fusion.
- Squash, merge commit ou rebase sont des stratégies qui façonnent l'historique ; chaque équipe en choisit une.
Erreurs fréquentes
- Regrouper des changements sans rapport dans une même pull request.
- Approuver sans ouvrir la préversion ni lire le diff.
- Fusionner malgré des vérifications en échec, sous la pression du calendrier.
Pour aller plus loin dans Module
Les formations et les leçons qui traitent cette notion :