# Pull request dans Git : qu'est-ce que c'est et comment créer une PR sur GitHub

URL: https://skillaria.top/fr/guides/git/git-pull-request-creer

Une pull request (PR) est une demande de fusion de votre branche dans la branche principale du dépôt sur GitHub : vous montrez vos modifications, l'équipe les commente et les vérifie, puis la branche est fusionnée après approbation. Sur GitLab, on parle de merge request (MR). C'est une fonctionnalité de la plateforme et non une commande Git, et elle n'a aucun lien avec la commande git pull.

Une pull request (PR) est une proposition d'intégrer les modifications d'une branche dans une autre, formalisée sur une plateforme comme GitHub. Vous envoyez votre branche sur le serveur, ouvrez une PR, et l'équipe consulte le diff, commente des lignes, lance les vérifications automatiques, puis seulement clique sur le bouton de fusion. Sur GitLab, le même mécanisme s'appelle merge request (MR). En résumé, la pull request est le point de contrôle entre « j'ai écrit le code » et « le code est arrivé dans main ».

## Pull request Git : qu'est-ce que c'est et d'où vient le nom

Le nom s'est imposé historiquement. L'auteur des modifications demande au responsable du dépôt de « tirer » (pull) sa branche chez lui : d'où pull request. GitLab a préféré un nom décrivant le résultat, merge request, c'est-à-dire demande de fusion. Bitbucket et Azure DevOps utilisent « pull request ». Sur le fond, c'est la même chose : une branche source, une branche cible, une description, une discussion, des vérifications et un bouton de fusion.

Il faut bien comprendre que la pull request ne fait pas partie de Git. Git ne connaît pas d'objet « PR » : on ne peut pas la créer avec un commit ni la trouver dans le dossier `.git`. C'est une entité de la plateforme : GitHub conserve la description, les commentaires et l'état des vérifications, tandis que Git ne gère que les branches et les commits qu'elle contient.

Dans le langage des développeurs, l'abréviation PR désigne presque toujours la pull request : « envoie-moi la PR », « PR en revue », « PR fusionnée ». Pour GitLab, on dit MR.

## Pull request et git pull : la différence

Ces deux notions sont constamment confondues à cause de leur ressemblance. La commande `git pull` télécharge les nouveaux commits du dépôt distant et les fusionne immédiatement dans votre branche courante : c'est une opération locale, dans le terminal. La pull request est une page web sur GitHub qui propose de fusionner une branche dans une autre.

|  | git pull | Pull request |
| --- | --- | --- |

| Où elle vit | Commande Git dans le terminal | Page sur GitHub, GitLab, Bitbucket |

| Ce qu'elle fait | Rapatrie les modifications du serveur vers votre poste | Propose de fusionner votre branche dans une branche d'autrui ou partagée |

| Qui participe | Vous seul | Auteur, relecteurs, CI |

| Faut-il une plateforme | Non, un remote suffit | Oui |

Il n'existe pas de commande « git pull request » dans Git. On trouve l'ancien utilitaire `git request-pull`, mais il ne fait que générer le texte d'un e-mail récapitulant les modifications : il n'a rien à voir avec les PR sur GitHub.

## À quoi servent les pull requests

Tant qu'un projet n'est géré que par une personne, on peut committer directement dans main. Dès que deux personnes ou plus travaillent sur le dépôt, les push directs vers la branche principale deviennent une source de builds cassés et de travail perdu. La pull request répond à plusieurs besoins à la fois :

- **revue de code** — une deuxième personne voit les modifications avant qu'elles n'atteignent main et repère les erreurs que l'auteur a manquées ;
- **vérifications automatiques** — GitHub Actions ou un autre CI lance les tests et les linters à chaque PR, et un statut rouge empêche de fusionner du code défectueux ;
- **historique des décisions** — un an plus tard, la PR montre non seulement ce qui a changé, mais aussi pourquoi, avec la discussion ;
- **contribution à des projets tiers** — dans l'open source, vous n'avez pas de droit d'écriture, et la PR depuis un fork est le seul moyen de proposer une correction ;
- **protection des branches** — les règles de protection de GitHub peuvent interdire tout push direct sur main et exiger une PR approuvée.

## Créer une pull request sur GitHub depuis une branche

C'est le scénario principal pour une équipe dont tous les membres ont un droit d'écriture sur le dépôt. Le travail se fait dans une branche de fonctionnalité, et main n'évolue que via une PR.

### Étape 1. Créer une branche à partir d'un main à jour

```
git switch main
git pull
git switch -c feature/login-form
```

Donnez à la branche un nom parlant : `feature/…`, `fix/…`, le numéro de la tâche. Le relecteur comprend tout de suite de quoi il s'agit.

### Étape 2. Faire les commits

```
git add src/login.js
git commit -m "Ajouter le formulaire de connexion"
```

Une PR, une tâche. Une petite PR de 100 à 300 lignes se relit vite et avec attention ; une PR de 3000 lignes reçoit une approbation sans être vraiment lue.

### Étape 3. Envoyer la branche sur le serveur (git push pour une pull request)

```
git push -u origin feature/login-form
```

L'option `-u` relie la branche locale à la branche distante ; ensuite, un simple `git push` suffit. Dans la réponse, GitHub indique lui-même le lien pour créer la PR :

```
remote: Create a pull request for 'feature/login-form' on GitHub by visiting:
remote:      https://github.com/team/app/pull/new/feature/login-form
```

### Étape 4. Ouvrir la PR dans l'interface web

Suivez le lien affiché dans le terminal ou ouvrez le dépôt sur GitHub : après un push récent, une bannière avec le bouton « Compare & pull request » apparaît. Autre chemin : l'onglet « Pull requests » puis le bouton « New pull request ».

1. Vérifiez le couple de branches : base — la branche cible (en général `main`), compare — votre branche.
2. Rédigez le titre : ce qui a été fait, à l'infinitif ou sous forme de description courte.
3. Dans la description, expliquez pourquoi, comment vérifier et ce qui reste hors périmètre. Si le dépôt contient un modèle de PR, les champs se remplissent automatiquement.
4. À droite, désignez les relecteurs (Reviewers), la personne responsable (Assignees) et les labels si votre équipe les utilise.
5. Cliquez sur « Create pull request » ou choisissez un brouillon (voir plus bas).

### Créer une PR depuis le terminal : GitHub CLI

Si vous ne voulez pas quitter le terminal, l'outil officiel `gh` est disponible. Ce n'est pas une commande Git mais un programme distinct de GitHub, très pratique pour les PR :

```
gh pr create --base main --title "Ajouter le formulaire de connexion" --body "Closes #42"
gh pr list
gh pr checkout 57
gh pr merge 57 --squash
```

À la question des commandes Git pour les pull requests, la réponse honnête est la suivante : Git gère les branches, les commits et le push, mais la PR elle-même se crée sur la plateforme, dans le navigateur, avec `gh` ou via l'API.

## Faire une pull request dans un dépôt tiers via un fork

Dans les projets open source, vous n'avez pas de droit d'écriture. Il faut donc d'abord créer un fork, c'est-à-dire une copie personnelle du dépôt sur GitHub. Vous y travaillez, puis proposez vos modifications à l'original.

1. Sur la page du projet, cliquez sur « Fork » : vous obtenez `github.com/vous/projet`.
2. Clonez votre fork et ajoutez l'original comme second remote, généralement nommé `upstream`.
3. Créez une branche, faites vos commits et envoyez la branche sur votre fork.
4. Sur GitHub, ouvrez la PR : base repository — le projet original, head repository — votre fork avec votre branche.

```
git clone git@github.com:vous/projet.git
cd projet
git remote add upstream https://github.com/proprietaire/projet.git
git switch -c fix/typo-readme
git commit -am "Corriger une faute de frappe dans le README"
git push -u origin fix/typo-readme
```

Avant de commencer, jetez un œil au fichier `CONTRIBUTING.md` : il décrit en général les règles de messages de commit, les tests et l'éventualité d'ouvrir d'abord une issue. Gardez votre fork à jour avec `git fetch upstream` puis `git rebase upstream/main` dans votre branche, afin que la PR ne prenne pas de retard sur l'original.

## Merge request dans GitLab : définition et création

La merge request de la plateforme GitLab est l'équivalent complet de la pull request. Les noms et les détails de l'interface diffèrent, mais le déroulement est identique : branche, push, demande de fusion, revue, fusion.

Vous pouvez créer une MR de plusieurs façons :

- via le lien que GitLab affiche dans le terminal après le `git push` d'une nouvelle branche ;
- dans la section Merge requests du projet, avec le bouton « New merge request », en choisissant la branche source et la branche cible ;
- directement lors du push, grâce aux options de push de GitLab, sans passer par le navigateur.

```
git push -o merge_request.create -o merge_request.target=main origin feature/login-form
```

La terminologie de GitLab diffère un peu : l'approbation s'appelle approve, la personne responsable de la fusion est l'assignee, et GitLab CI/CD fonctionne avec le fichier `.gitlab-ci.yml` à la place de GitHub Actions. Les brouillons de MR existent aussi : on les appelle Draft.

## Revue d'une pull request

Le relecteur ouvre l'onglet « Files changed » et voit le diff. Il peut laisser un commentaire sur n'importe quelle ligne ou proposer une modification prête à l'emploi (suggestion) que l'auteur applique d'un clic. Les commentaires sont regroupés dans une revue et envoyés en même temps que l'un des verdicts suivants :

- **Comment** — de simples remarques, sans décision ;
- **Approve** — les modifications sont approuvées ;
- **Request changes** — des corrections sont nécessaires, la fusion n'est pas souhaitable.

Une bonne revue porte sur la logique, la lisibilité, les tests et les cas limites, et ne débat pas des préférences esthétiques : le formatage est mieux confié au linter du CI. L'auteur doit répondre à chaque commentaire : corrigé, discuté, ou laissé en l'état avec une justification.

### Vérifier localement une PR (git checkout pull request)

Il arrive qu'il faille exécuter le code chez soi. Si la branche se trouve dans le même dépôt, `git fetch` et `git switch` suffisent. Pour une PR issue d'un fork, GitHub fournit des références spéciales `pull/<numéro>/head` :

```
git fetch origin pull/57/head:pr-57
git switch pr-57
```

Sur GitLab, les références équivalentes s'appellent `merge-requests/<numéro>/head`. Ou bien utilisez simplement `gh pr checkout 57` si la GitHub CLI est installée.

## Mettre à jour une pull request après des remarques

La PR est liée à une branche, et non à des commits précis. Il suffit de faire de nouveaux commits dans la même branche et de les envoyer : la PR se met à jour toute seule, sans nouvelle demande à créer.

```
git commit -am "Prendre en compte les remarques de la revue"
git push
```

### Git rebase pour une pull request : récupérer le main à jour

Pendant que la PR est en revue, main continue d'avancer. Si GitHub signale que la branche est obsolète ou qu'il y a des conflits, mettez-la à jour. La variante avec rebase donne un historique linéaire :

```
git fetch origin
git rebase origin/main
# résoudre les conflits, git add, git rebase --continue
git push --force-with-lease
```

Après un rebase, les empreintes des commits changent, donc un push ordinaire est refusé : il faut un push forcé. Utilisez `--force-with-lease` : il refuse d'écraser la branche si des commits de quelqu'un d'autre y sont apparus. Si d'autres personnes travaillent aussi sur la branche, il est plus sûr d'intégrer main avec `git merge origin/main`, sans réécrire l'historique.

## Fusionner une pull request : merge, squash et rebase

Une fois la revue approuvée et les vérifications vertes, la PR peut être fusionnée. GitHub propose trois méthodes, et l'administrateur du dépôt peut en désactiver certaines.

| Méthode | Résultat dans main | Quand l'utiliser |
| --- | --- | --- |

| Create a merge commit | Tous les commits de la branche plus un commit de fusion | Quand on veut l'historique complet et voir quels commits sont arrivés ensemble |

| Squash and merge | Un seul commit regroupant toutes les modifications de la PR | Quand la branche contient beaucoup de petits « fix typo » et que le journal de main doit rester propre |

| Rebase and merge | Les commits de la branche un à un, sans commit de fusion | Quand les commits sont soignés et ont chacun un sens propre |

Fusionner une PR depuis l'interface revient au fond à un `git merge` exécuté sur le serveur. Après la fusion, GitHub propose de supprimer la branche : acceptez, elle ne sert plus. Ensuite, nettoyez en local :

```
git switch main
git pull
git branch -d feature/login-form
```

Il est aussi possible de fusionner une PR à la main dans le terminal : intégrer la branche dans main en local puis pousser. GitHub constate que les commits de la branche sont arrivés dans la base et marque lui-même la PR comme fusionnée. Mais on perd alors les vérifications et les règles de protection de la branche ; c'est pourquoi, en pratique, on fusionne avec le bouton.

### Auto-merge et file de fusion

Si les vérifications sont longues, vous pouvez activer la fusion automatique : la PR se fusionne toute seule dès que toutes les conditions sont remplies. Dans les grands dépôts, on utilise une file de fusion (merge queue), qui teste chaque PR par-dessus celles déjà en file d'attente, afin que main ne casse pas à cause de modifications incompatibles.

## Brouillons de pull request (Draft)

Un brouillon est une PR qui n'est pas encore prête pour la revue. Elle ne peut pas être fusionnée, et les relecteurs ne reçoivent pas de demande de contrôle. Les brouillons sont pratiques pour montrer tôt une direction, lancer le CI ou recueillir un avis sur l'architecture. Sur GitHub, choisissez l'option brouillon dans le menu déroulant du bouton de création ou exécutez `gh pr create --draft`. Lorsque le travail est prêt, cliquez sur « Ready for review ». Sur GitLab, un brouillon est signalé par le préfixe `Draft:` dans le titre de la MR.

## Lier une pull request aux issues

Si vous écrivez dans la description de la PR un mot-clé suivi du numéro de la tâche, GitHub ferme automatiquement l'issue après la fusion dans la branche par défaut :

```
Closes #42
Fixes #17
Resolves #8
```

Les mots close, fix et resolve fonctionnent sous leurs différentes formes (closes, fixed, resolves). La simple mention `#42`, sans mot-clé, crée seulement un lien mais ne ferme pas la tâche. Sur GitLab, `Closes #42` et des formulations similaires fonctionnent de la même manière.

## Peut-on supprimer une pull request ou une merge request ?

Sur GitHub, un participant ordinaire ne peut pas supprimer une PR : il peut seulement la fermer avec le bouton « Close pull request ». Une PR fermée reste dans l'historique et peut être rouverte. Supprimez la branche séparément après la fermeture. Une suppression complète n'est possible que via le support de GitHub, par exemple si des secrets se sont retrouvés dans la PR.

Sur GitLab, l'auteur ou un participant disposant des droits suffisants peut fermer la MR, et seuls le propriétaire du projet ou un administrateur peuvent la supprimer. Si un mot de passe ou un jeton s'est glissé dans une PR, la fermeture ne suffit pas : révoquez immédiatement le secret, car les commits étaient déjà sur le serveur.

## Erreurs fréquentes avec les pull requests

- **PR depuis main.** Vous avez committé dans votre main et ouvert la PR depuis lui. La PR suivante contiendra alors aussi les anciennes modifications. Travaillez toujours dans une branche dédiée.
- **Mauvaise branche de base.** La PR a été ouverte vers `develop` au lieu de `main`, ou l'inverse. La base se modifie avec le bouton Edit à côté du titre de la PR.
- **Fichiers superflus dans le diff.** Builds, `node_modules`, `.env`. Ajoutez-les au `.gitignore` et retirez-les de l'index avec `git rm --cached`.
- **PR énorme.** Découpez la tâche en plusieurs PR successives.
- **Push ordinaire après un rebase.** Erreur `rejected (non-fast-forward)`. Il faut `git push --force-with-lease`, et non `--force`.
- **Conflits.** Ne les résolvez pas à l'aveugle dans l'éditeur web : récupérez main en local, résolvez et vérifiez les tests.

## Pull request avec Git Flow et les autres processus

La pull request s'intègre à n'importe quel processus d'équipe. Dans GitHub Flow, tout est simple : branche depuis main, PR, revue, fusion, déploiement. Avec Git Flow, les PR des branches de fonctionnalité sont ouvertes vers `develop`, et les branches de release et de hotfix passent elles aussi par une PR vers `main`. En développement trunk-based, les PR sont courtes et vivent quelques heures plutôt que quelques jours. Quel que soit le processus, la règle reste la même : les modifications des branches partagées passent uniquement par une pull request.

## Conclusion

La pull request est un mécanisme de la plateforme, et non une commande Git : une branche envoyée sur le serveur, plus une page de discussion, de revue et de vérifications. Sur GitLab, il s'agit d'une merge request ; dans le langage courant, on dit PR ou MR. Créez vos PR depuis une branche dédiée, gardez-les petites, mettez-les à jour par push dans la même branche et choisissez la méthode de fusion en fonction de l'historique du projet. Forks, branches de fonctionnalité et pull requests sont traités en pratique dans le cours sur Git.

## FAQ

**Combien de relecteurs faut-il pour une pull request ?**

En général, un ou deux suffisent. Le nombre minimal d'approbations est défini dans les règles de protection de la branche ; sans elles, le bouton de fusion n'est pas disponible.

**Peut-on créer une pull request sans fork ?**

Oui, si vous avez un droit d'écriture sur le dépôt : créez la branche directement dans celui-ci et ouvrez la PR depuis elle. Le fork n'est nécessaire que si vous n'avez pas de droit d'écriture.

**Que faire si personne ne regarde ma PR depuis longtemps ?**

Relancez poliment le relecteur dans un commentaire ou sur le chat de l'équipe. Dans les projets open source, l'attente peut durer des semaines ; vérifiez aussi que la PR respecte les règles du fichier CONTRIBUTING.md.

**Peut-on ouvrir une pull request entre deux branches de son propre fork ?**

Oui, sur la page de comparaison, sélectionnez votre fork comme base et comme head. C'est pratique pour relire ses propres modifications avant de les envoyer au projet original.

**Pourquoi la PR affiche-t-elle des commits que je n'ai pas faits ?**

Probablement la branche n'a pas été créée à partir d'un main à jour, ou la mauvaise branche de base a été choisie. Faites un rebase sur le main récent ou changez la base dans les paramètres de la PR.


---
Source: Skillaria.Top (https://skillaria.top)