🎯 Objectifs de ce chapitre
À la fin de ce chapitre, tu seras capable de :
- Comprendre ce qu'est une Pull Request (PR) et son utilité
- Créer une Pull Request sur GitHub
- Rédiger une description claire pour ta PR
- Participer à une revue de code (code review)
- Fusionner une Pull Request
- Appliquer les bonnes pratiques pour des PR efficaces
Qu'est-ce qu'une Pull Request ?
Une Pull Request (demande de tirage) est une proposition de fusionner des changements d'une branche vers une autre. C'est le cœur de la collaboration sur GitHub !
🔀 Comprendre les Pull Requests
Analogie : Proposition d'amélioration
Une PR, c'est comme dire à tes collègues : "J'ai fait ces améliorations, qu'est-ce que vous en pensez ? Pouvons-nous les intégrer au projet principal ?"
Pourquoi utiliser les Pull Requests ?
Revue de code
Permet à d'autres développeurs de vérifier ton code avant qu'il ne soit fusionné
Discussion
Crée un espace pour discuter des améliorations et des problèmes
Qualité
Améliore la qualité du code grâce aux retours des autres
Documentation
Crée un historique des décisions et des changements
Différence entre merge et PR
git merge : Fusionne directement des branches (sans discussion)
Pull Request : Propose une fusion et permet la discussion avant
Quand utiliser les PR ?
Utilise toujours des PR quand tu travailles en équipe. Même en solo, c'est une bonne pratique pour revoir ton propre code !
🚀 Créer ta première Pull Request
Prépare ton travail
Travaille sur une branche et pousse-la sur GitHub :
git checkout -b ma-nouvelle-fonctionnalite
# ... travaille et fais tes commits ...
git push origin ma-nouvelle-fonctionnaliteVa sur GitHub
Ouvre ton dépôt sur GitHub. Tu devrais voir une bannière te proposant de créer une PR.
Crée la Pull Request
Clique sur "Compare & pull request" et remplis les informations.
Rédiger une bonne description de PR
## Description
Cette PR ajoute une fonctionnalité de recherche dans l'application.
## Changements
- Ajout du composant SearchBar
- Implémentation de la logique de recherche
- Tests unitaires pour la recherche
## Test
✅ Tester la recherche avec différents termes
✅ Vérifier les résultats pertinents
✅ Tester le cas "aucun résultat"
Éléments essentiels d'une bonne PR
- 📝 Titre clair : Explique ce que fait la PR
- 📋 Description détaillée : Ce qui change et pourquoi
- 🔍 Instructions de test : Comment tester les changements
- 🖼️ Captures d'écran : Si c'est une fonctionnalité visuelle
- 📎 Issues liées : Référence les tickets concernés
🔍 Revue de code (Code Review)
La revue de code est un processus collaboratif pour améliorer la qualité du code.
En tant que réviseur
- ✅ Sois constructif et bienveillant
- ✅ Pose des questions plutôt que de critiquer
- ✅ Vérifie la logique et les cas limites
- ✅ Teste les changements si possible
- ✅ Réponds rapidement
En tant que auteur
- ✅ Sois ouvert aux retours
- ✅ Explique tes choix techniques
- ✅ Corrige les problèmes identifiés
- ✅ Remercie pour les retours
- ✅ Apprends des commentaires
Types de commentaires en revue de code
Commentaires utiles
"As-tu pensé à gérer le cas où X serait null ?"
"Cette partie pourrait être extraite dans une fonction pour plus de clarté"
"Super idée ! Peut-être ajouter un test pour ce cas ?"
Commentaires à éviter
"Ton code est mauvais"
"Pourquoi tu as fait ça comme ça ?"
"Refais tout"
Processus de revue typique
- Auteur : Crée la PR et demande une revue
- Réviseur : Examine le code et laisse des commentaires
- Auteur : Corrige les problèmes identifiés
- Réviseur : Approuve la PR une fois satisfait
- Auteur : Fusionne la PR
✅ Fusionner une Pull Request
Une fois la PR approuvée, tu peux la fusionner.
Vérifie que tout est prêt
Assure-toi que :
- ✅ La PR a été approuvée
- ✅ Les tests passent
- ✅ Les conflits sont résolus
- ✅ La description est à jour
Choisis la méthode de fusion
GitHub propose plusieurs options :
- Merge commit : Crée un commit de fusion
- Squash and merge : Combine tous les commits en un
- Rebase and merge : Réécrit l'historique
Fusionne la PR
Clique sur "Merge pull request" et confirme.
Méthodes de fusion recommandées
Squash and merge (recommandé pour débutants)
Combine tous les commits de la branche en un seul commit propre. Garde l'historique de main linéaire et facile à lire.
Merge commit (équipes expérimentées)
Conserve tous les commits individuels. Utile pour suivre l'historique détaillé du développement.
Après la fusion
N'oublie pas de :
- 🗑️ Supprimer la branche sur GitHub
- 🧹 Nettoyer en local :
git branch -d ma-branche - 📥 Mettre à jour main :
git checkout main && git pull
🎯 Bonnes pratiques pour des PR efficaces
PR petites et focussées
Fais : Une PR = une fonctionnalité
Évite : Les PR énormes avec 50 fichiers modifiés
Descriptions claires
Fais : Explique le POURQUOI et le COMMENT
Évite : Les descriptions vagues ou absentes
Tests inclus
Fais : Inclus les tests pour tes changements
Évite : Le code non testé
Revues rapides
Fais : Réponds rapidement aux PR
Évite : Laisser les PR en attente des semaines
Workflow professionnel typique
git checkout -b feature/ma-fonctionnalite- Travaille et fais des commits réguliers
git push origin feature/ma-fonctionnalite- Crée une PR sur GitHub avec une description détaillée
- Demande une revue à tes collègues
- Incorpore les retours (fais de nouveaux commits)
- Une fois approuvé, fusionne avec "Squash and merge"
- Supprime la branche sur GitHub et en local
✅ Résumé du chapitre
Ce que tu as accompli
- ✅ Compris le concept des Pull Requests et leur importance
- ✅ Appris à créer une PR avec une bonne description
- ✅ Découvert la revue de code et les bonnes pratiques
- ✅ Maîtrisé les méthodes de fusion (squash, merge, rebase)
- ✅ Appris les bonnes pratiques pour des PR efficaces
- ✅ Compris le workflow collaboratif professionnel
Félicitations ! Tu maîtrises maintenant un des outils les plus puissants de la collaboration sur GitHub. Dans le prochain chapitre, nous verrons comment utiliser les Issues pour gérer les tâches et les bugs.
Pour t'entraîner
Crée plusieurs petites branches avec des améliorations simples et pratique la création de PR. Plus tu pratiques, plus le processus deviendra naturel !