Aller au contenu principal

Pull Requests — Revue de code professionnelle

Module 04 60 min

Objectifs de la section

  • Comprendre le rôle des Pull Requests dans la collaboration professionnelle
  • Créer des PRs bien documentées
  • Effectuer des revues de code de qualité
  • Gérer le cycle de vie complet d'une PR
  • Utiliser les fonctionnalités avancées des PRs GitHub

Qu'est-ce qu'une Pull Request ?

Une Pull Request (PR) est une demande de fusion de votre branche dans une autre. C'est le mécanisme principal de :

  • Revue de code : d'autres développeurs vérifient vos changements
  • Discussion : discussion sur le code avant la fusion
  • CI/CD : déclenchement automatique des tests
  • Traçabilité : documentation de pourquoi chaque changement a été fait

Créer une Pull Request de qualité

Via GitHub CLI

# Créer une PR basique
gh pr create --title "feat: ajout de l'authentification utilisateur" --base main

# Créer une PR avec un corps détaillé
gh pr create \
--title "feat(auth): ajout du système de connexion complet" \
--base main \
--body "## Description

Implémente le système d'authentification complet incluant :
- Formulaire de connexion avec validation
- Intégration JWT pour les sessions
- Déconnexion sécurisée
- Tests unitaires (couverture 85%)

## Changements
- feat: formulaire de connexion avec validation email/password
- feat: service JWT pour génération et vérification de tokens
- test: ajout de 15 tests unitaires

## Comment tester
1. \`pip install -r requirements.txt\`
2. \`python -m pytest tests/test_auth.py\`
3. Démarrer le serveur et aller sur /login

Closes #42
Reviewed-by: @coequipier"

Via l'interface GitHub

  1. Allez dans l'onglet Pull Requests du dépôt
  2. Cliquez sur New pull request
  3. Sélectionnez : base = main, compare = votre branche
  4. Cliquez sur Create pull request
  5. Remplissez le titre et la description

Template de PR (bonne pratique)

Créez .github/pull_request_template.md dans votre dépôt :

## Description
Résumé clair des changements effectués.

## Type de changement
- [ ] Correction de bug
- [ ] Nouvelle fonctionnalité
- [ ] Breaking change
- [ ] Mise à jour de documentation

## Comment tester
Étapes pour tester les changements :
1. ...
2. ...

## Checklist
- [ ] Mon code suit les conventions du projet
- [ ] J'ai ajouté des tests
- [ ] Les tests existants passent
- [ ] J'ai mis à jour la documentation
- [ ] Pas de secrets dans le code

Closes #(numéro d'issue)

Effectuer une revue de code

Principes d'une bonne revue

Les règles d'or de la revue de code
  1. Critiquer le code, pas la personne : "Cette fonction pourrait être simplifiée" pas "Tu n'aurais pas dû écrire ça comme ça"
  2. Être constructif : Proposer une solution quand vous signalez un problème
  3. Reconnaître le bon travail : Les commentaires positifs motivent l'équipe
  4. Être précis : Pointer la ligne exacte, pas "quelque part dans le fichier"
  5. Approuver quand c'est prêt : Ne pas bloquer indéfiniment

Types de commentaires GitHub

# Commentaire général sur la PR
"Bonne implémentation globale ! Quelques suggestions..."

# Suggestion de code (directement applicable)
```suggestion
def calculer_total(articles):
return sum(a['prix'] * a.get('quantite', 1) for a in articles)

Commentaire sur une ligne spécifique

"Ce magic number devrait être une constante nommée."

Demande de changement obligatoire

"Cette validation est manquante et peut causer un crash en production."


### Via GitHub CLI

```bash
# Voir les PRs ouvertes
gh pr list

# Voir les détails d'une PR
gh pr view 42

# Revoir une PR en ligne de commande
gh pr review 42 --approve
gh pr review 42 --request-changes --body "Veuillez ajouter des tests unitaires"
gh pr review 42 --comment --body "Quelques suggestions mineures"

# Checkout d'une PR localement pour tester
gh pr checkout 42

Gérer le cycle de vie d'une PR

# Mettre à jour une PR après des retours
git switch feature/login
# Faire les corrections demandées
git add .
git commit -m "fix(auth): corriger la validation email selon les retours de revue"
git push

# La PR est automatiquement mise à jour !

# Fusionner une PR (si vous êtes le mainteneur)
gh pr merge 42 --squash --delete-branch

# Fermer une PR sans fusionner
gh pr close 42

Stratégies de merge des PRs

StratégieQuand l'utiliserRésultat
Merge commitPréserver tout l'historiqueCommit de merge créé
Squash and mergeNettoyer les WIP commitsUn seul commit propre
Rebase and mergeHistorique linéaireCommits rebased sur main

Protection des branches

Configurez sur GitHub → Settings → Branches → Branch protection rules :

✅ Require pull request reviews before merging (1-2 reviewers)
✅ Require status checks to pass before merging (CI tests)
✅ Require branches to be up to date before merging
✅ Restrict who can push to matching branches

Résumé des commandes clés

CommandeDescription
gh pr createCréer une Pull Request
gh pr listLister les PRs ouvertes
gh pr view <num>Voir les détails d'une PR
gh pr checkout <num>Checkout local d'une PR
gh pr review <num>Approuver/demander des changements
gh pr merge <num>Fusionner une PR
gh pr close <num>Fermer sans fusionner

Prochaines étapes