La pull request expliquée : bien collaborer sur GitHub

La pull request (ou PR) est le cœur battant de la collaboration sur GitHub. C’est le mécanisme par lequel vous proposez vos changements, les faites relire, discutez ligne par ligne, puis intégrez le tout au projet. Bien maîtrisée, elle transforme le travail en équipe en un processus fluide et sûr ; mal comprise, elle génère des conflits et des allers-retours pénibles. Ce guide décortique tout le cycle : du fork à la fusion, en passant par la revue et la résolution des conflits.

Qu’est-ce qu’une pull request

Une pull request est une demande d’intégration : vous dites au dépôt « voici une branche contenant mes modifications, merci de les examiner et de les fusionner ». Malgré son nom, elle ne « tire » rien automatiquement — c’est avant tout un espace de discussion et de revue construit autour d’un ensemble de commits.

Une PR compare deux branches : la branche source (vos changements) et la branche cible (généralement main). GitHub affiche la différence, permet de commenter chaque ligne, lance les tests automatisés, et n’autorise la fusion qu’une fois tout le monde d’accord. C’est un garde-fou qui empêche d’envoyer directement du code non relu dans la branche principale.

Deux workflows : branche ou fork

Il existe deux façons d’arriver à une PR, selon vos droits sur le dépôt.

Le workflow par branche s’applique quand vous êtes membre du projet et pouvez y pousser. Vous créez une branche dédiée, y travaillez, la poussez, puis ouvrez la PR.

# Se placer sur main et récupérer la dernière version
git switch main
git pull

# Créer une branche dédiée à votre fonctionnalité
git switch -c feature-recherche

# ... modifications, puis :
git add .
git commit -m "Ajoute la barre de recherche"
git push -u origin feature-recherche

Le workflow par fork s’applique aux projets où vous n’avez pas les droits d’écriture (typiquement l’open source). Vous cliquez sur Fork pour créer votre copie personnelle du dépôt, vous y poussez votre branche, puis vous ouvrez une PR depuis votre fork vers le dépôt d’origine.

# Cloner votre fork
git clone https://github.com/vous/projet.git
cd projet

# Ajouter le dépôt d'origine comme remote "upstream"
git remote add upstream https://github.com/original/projet.git

# Rester à jour avec le projet d'origine
git fetch upstream
git switch main
git merge upstream/main

Ce second remote, upstream, est essentiel : il vous permet de synchroniser votre fork avec le projet d’origine qui continue d’évoluer pendant que vous travaillez.

Ouvrir la pull request

Une fois votre branche poussée, GitHub affiche un bandeau proposant de créer la PR — ou passez par l’onglet Pull requests > New. Vérifiez que les branches source et cible sont correctes, puis rédigez :

un titre clair et concis (« Ajoute la barre de recherche produits ») ;
une description qui explique le pourquoi, pas seulement le quoi : le problème résolu, les choix techniques, ce qui reste à faire.

Bonne pratique — une PR = une intention Gardez vos pull requests petites et focalisées. Une PR qui touche 40 fichiers pour trois fonctionnalités différentes est un cauchemar à relire. Un changement = une PR : la revue est plus rapide, les bugs plus faciles à repérer, et la fusion moins risquée.

Si le dépôt utilise un template de PR, remplissez-le : il liste souvent une checklist (tests ajoutés, documentation mise à jour) qui fait gagner du temps à tout le monde.

La revue de code

C’est le moment central. Les relecteurs parcourent l’onglet Files changed, où chaque ligne peut recevoir un commentaire. Ils peuvent :

commenter une ligne pour poser une question ou suggérer une amélioration ;
proposer une suggestion de code directement applicable en un clic ;
rendre un verdict : Approve (validé), Request changes (modifications demandées) ou Comment (remarque neutre).

De votre côté, répondez aux commentaires, poussez de nouveaux commits sur la même branche — ils apparaissent automatiquement dans la PR — et relancez la discussion. Ce va-et-vient est normal et sain : il diffuse la connaissance dans l’équipe et améliore le code.

Côté attitude, restez factuel et bienveillant des deux côtés. Une revue critique le code, jamais la personne. Une bonne PR se lit comme une conversation, pas comme un tribunal.

Résoudre les conflits

Pendant que votre PR mûrit, main continue d’avancer. Si quelqu’un modifie les mêmes lignes que vous, GitHub signale un conflit et bloque la fusion. Il faut alors réconcilier les deux versions localement :

# Récupérer la branche cible à jour
git switch main
git pull

# Revenir sur votre branche et y intégrer main
git switch feature-recherche
git merge main

Git marque les zones en conflit dans les fichiers concernés :

<<<<<<< HEAD
const titre = "Recherche produits";
=======
const titre = "Rechercher un produit";
>>>>>>> main

Vous choisissez la bonne version (ou une combinaison des deux), supprimez les marqueurs <<<<, ==== et >>>>, puis validez :

git add fichier.js
git commit -m "Résout le conflit sur le titre de recherche"
git push

La PR se met à jour et redevient fusionnable. Si vous manipulez encore mal les branches, notre mémo des commandes Git essentielles couvre merge, rebase et compagnie en détail.

Fusionner : merge, squash ou rebase

GitHub propose trois stratégies de fusion, chacune avec sa logique :

Stratégie	Ce qu’elle fait	Quand l’utiliser
Merge commit	Ajoute un commit de fusion, garde tous vos commits	Historique complet, traçabilité fine
Squash and merge	Compresse tous les commits de la PR en un seul	Historique propre, une PR = un commit
Rebase and merge	Rejoue vos commits sur la cible, sans commit de fusion	Historique linéaire, sans commit de merge

Le squash est souvent le choix par défaut des équipes : il garde main lisible avec un commit par fonctionnalité, tout en préservant le détail dans la PR archivée. Une fois la fusion faite, supprimez la branche (GitHub le propose automatiquement) pour ne pas encombrer le dépôt.

Les bonnes pratiques en résumé

Pour des PR qui avancent vite et bien :

Petites et ciblées : un objectif par pull request.
Une description qui explique le pourquoi, pas juste le quoi.
À jour avec la cible avant d’ouvrir, pour limiter les conflits.
Réactif aux commentaires : répondez, corrigez, faites avancer.
Verte au vert : attendez que les tests automatisés passent avant de fusionner.

La pull request n’est pas une formalité administrative : c’est le lieu où la qualité se construit collectivement. En la traitant comme une conversation structurée autour du code, vous transformez la contrainte de la relecture en un vrai levier de qualité et d’apprentissage.