Pull Request (PR)
Définition
Une pull request (PR) est le mécanisme standard pour proposer des changements dans un workflow basé sur Git. Elle encapsule un ensemble de commits, un diff lisible par l'humain, des vérifications automatiques et un fil de discussion afin que l'équipe puisse évaluer la justesse, la sécurité, la performance et l'impact produit avant la fusion dans la branche cible. Les équipes matures considèrent la PR comme la source de vérité du ‘pourquoi’ et du ‘comment’ d'un changement, de la rationale de conception jusqu'au plan de déploiement et de retour arrière.
Flux de travail typique
Partez d'une base à jour, créez une branche de fonctionnalité et commitez par petites étapes cohérentes. Poussez votre branche puis ouvrez une PR avec un titre clair et orienté action et un périmètre concis. Liez les issues pertinentes, ajoutez des captures ou des vidéos et signalez les migrations ou impacts visibles. Demandez les reviewers et code owners appropriés. La CI s'exécute automatiquement (formatage, lint, typage, tests, build, sécurité). Itérez jusqu'à obtenir des checks verts et les approbations, puis fusionnez avec la stratégie adaptée, nettoyez la branche et publiez des notes de version si nécessaire.
Un processus de revue efficace
Les reviewers se concentrent sur la justesse, la sécurité, l'adéquation architecturale, la performance, la lisibilité et la couverture de tests. Préférez des commentaires spécifiques et constructifs; distinguez blocages et détails; proposez des suggestions concrètes quand c'est pertinent. Les auteurs clarifient l'intention, répondent rapidement et maintiennent la PR synchronisée avec la base. Les conversations se marquent comme résolues une fois traitées; les PR obsolètes doivent être rebasées ou fermées pour assainir le backlog.
Stratégies de fusion et historique
Trois approches courantes : Merge Commit (préserve l'historique et le contexte), Squash & Merge (un commit propre qui capture l'état final de la PR) et Rebase & Merge (garantit un historique linéaire). Le squash est souvent préféré pour les branches de feature; les merge commits sont utiles pour les efforts collaboratifs; le rebase est idéal quand un historique strictement linéaire est requis. Choisissez une stratégie par dépôt et documentez les exceptions.
Vérifications CI et automatisation
Automatisez les vérifications répétables : formatage, lint, typage, tests unitaires/intégration/E2E, build, environnements de prévisualisation, scans de sécurité (SAST/DAST), dépendances et licences, budgets de poids et migrations de base de données. Protégez les branches cibles avec des checks et règles d'approbation requis. Utilisez des bots pour étiqueter, assigner, mettre à jour les changelogs et, si souhaité, auto‑fusionner lorsque tous les critères sont remplis.
Templates et PR en brouillon
Un template de PR aide à capturer le ‘pourquoi’ et le ‘comment’ : problème, solution proposée, captures, plan de tests, notes de migration, risques, stratégie de déploiement/retour arrière et liens vers la spécification. Les PR en brouillon sont idéales pour un feedback précoce; passez en prêt pour revue quand le périmètre est stabilisé.
Bonnes pratiques
Privilégiez des PR petites et ciblées (quelques centaines de lignes de diff), des titres et résumés descriptifs, des commits atomiques, des tests et docs à jour, et évitez de mélanger des refactors sans lien. Utilisez des conventions de commits (Conventional Commits) pour rendre l'historique scannable. Dans la description, mettez l'accent sur le ‘pourquoi’ plutôt que de répéter le diff.
Pièges fréquents
PR trop volumineuses, fusions sans revue, tests ignorés, force‑push pendant une revue sans contexte, changements non liés glissés dans la même PR, checks instables masquant des régressions, migrations ou rollback manquants, et absence de considérations performance ou accessibilité.
Sécurité et conformité
Activez le scan de secrets, les mises à jour de dépendances et les alertes de scan de code. Exigez des approbations des code owners pour les zones sensibles et une double revue si nécessaire. Signez les commits si requis, évitez de journaliser des données sensibles et considérez la PR comme un artefact d'audit avec décisions et contrôles traçables.
Travailler en monorepo
En monorepo, une PR peut toucher plusieurs packages. Limitez le périmètre à un changement cohérent, exécutez uniquement les tests affectés et coordonnez‑vous avec les owners. Utilisez des changesets ou un outil de release pour saisir les versions et notes. Gardez les refactors trans‑packages petits, ou scindez en PR incrémentales.
Mesures et gouvernance
Suivez le lead time, la latence de revue, le temps jusqu'à la fusion et le taux d'échec des changements. Définissez des attentes de service pour les revues, utilisez des branches protégées et adoptez une gouvernance légère afin que les signaux de qualité restent constants sans ralentir les équipes.