> Comprendre la pull request sur GitHub : workflow fork et branche, ouverture, revue de code, résolution des conflits, merge squash ou rebase, bonnes pratiques. *Source : https://coder-studio.com/outils/pull-request-guide/* --- [// GitHub & Git](https://coder-studio.com/outils/) # La pull request expliquée : bien collaborer sur GitHub Par **Kévin Papot** · publié le 20 février 2026 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](https://coder-studio.com/outils/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. ## À lire ensuite - [Git : les commandes essentielles (mémo)](https://coder-studio.com/outils/commandes-git-essentielles/) - [GitHub Desktop : gérer ses dépôts sans ligne de commande](https://coder-studio.com/outils/github-desktop-guide/) - [GitHub pour débutants : le guide pour bien démarrer](https://coder-studio.com/outils/github-guide-debutant/)