Chapitre 8Projet GitFlow Portfolio

Pull Requests — La revue de code

Créer et merger des PRs sur GitHub

Concepts Théoriques

Une Pull Request (PR) est une demande de fusion d'une branche dans une autre, faite via l'interface GitHub. C'est l'outil central de la collaboration professionnelle.

Pourquoi ne pas merger directement ?

En entreprise, personne ne merge directement dans main. Chaque changement passe par une PR qui est relue par un autre développeur. Cela permet de :

  • Détecter les bugs avant qu'ils n'arrivent en production
  • Partager les connaissances — les reviewers découvrent votre code
  • Maintenir la qualité — cohérence du style et des conventions
  • Documenter — la PR décrit POURQUOI le changement a été fait

Le workflow Pull Request

  1. Créer une branche : git checkout -b feature/contact-form
  2. Travailler et commiter
  3. Pousser la branche sur GitHub : git push -u origin feature/contact-form
  4. Sur GitHub, créer une Pull Request (bouton "Compare & pull request")
  5. Remplir le titre et la description (quoi, pourquoi, comment tester)
  6. Demander une review (assign un reviewer)
  7. Le reviewer lit le code, commente, approuve ou demande des changements
  8. Corriger si nécessaire (nouveaux commits sur la même branche)
  9. Merger via l'interface GitHub (bouton "Merge pull request")
  10. Supprimer la branche sur GitHub (bouton "Delete branch")
  11. En local : git checkout main && git pull && git branch -d feature/contact-form

Rédiger une bonne description de PR

Un bon titre : "feat: ajout du formulaire de contact avec validation"

Un bon corps de description :

  • Quoi : ce que la PR fait
  • Pourquoi : le contexte ou le problème résolu
  • Comment tester : les étapes pour vérifier que ça fonctionne
  • Captures d'écran : si c'est un changement visuel

Protéger la branche main

Dans Settings > Branches > Branch protection rules, vous pouvez exiger :

  • Au moins 1 review approbative avant le merge
  • Que les tests CI passent avant le merge
  • Interdire les push directs sur main

> Même en solo, utilisez des PRs. Elles vous forcent à relire votre propre code, à écrire des descriptions, et à garder un historique propre.