Pull requests et code review

Une pull request (PR) — ou merge request (MR) sur GitLab — est une demande d’intégration de votre branche dans une autre. C’est le mécanisme central de la collaboration moderne : votre code est relu, discuté et validé avant d’être mergé. Ce guide couvre le workflow complet, de la création à l’intégration.

Prérequis : Workflows distribués et Merge et conflits.

Ce que vous allez apprendre

Créer une Pull Request bien structurée pour faciliter la revue
Conduire une revue de code constructive sans bloquer l’équipe
Naviguer dans le cycle de vie d’une PR de l’ouverture à la fusion
Gérer les retours : amendments, force-push et itérations

Le cycle de vie d’une PR

1. Créer une branche
        ↓
2. Commiter et pousser
        ↓
3. Ouvrir la PR
        ↓
4. Review + discussions
        ↓
5. Corrections (si demandées)
        ↓
6. Approbation
        ↓
7. Merge
        ↓
8. Suppression de la branche

Créer une PR : le workflow Git

Créez une branche depuis main à jour :

git switch main
git pull origin main
git switch -c feature/user-avatar

Travaillez avec des commits atomiques :

# Chaque commit = un changement logique
git add src/components/Avatar.tsx
git commit -m "feat: ajouter le composant Avatar"

git add src/pages/profile.tsx
git commit -m "feat: intégrer Avatar dans la page profil"

Rebasez sur main avant de pousser (pour éviter les conflits) :
Fenêtre de terminal
```
git fetch origin
git rebase origin/main
```
Poussez votre branche :
Fenêtre de terminal
```
git push -u origin feature/user-avatar
```
Ouvrez la PR sur GitHub/GitLab via l’interface web

Rédiger une bonne PR

Une PR bien rédigée accélère la review et réduit les allers-retours.

Le titre

Court, descriptif, au format conventionnel :

feat: ajouter le composant Avatar avec upload d'image
fix: corriger le redirect après déconnexion
docs: documenter l'API de notifications

La description

Structurez avec ces sections :

## Contexte
Pourquoi cette modification est nécessaire.

## Changements
- Ajout du composant `Avatar` (upload + crop)
- Intégration dans la page profil
- Tests unitaires pour le crop

## Comment tester
1. Aller sur /profil
2. Cliquer sur l'avatar
3. Uploader une image > 2 Mo → vérifier le message d'erreur

## Captures d'écran
(si changement visuel)

Bonnes pratiques de taille

Taille de PR	Lignes modifiées	Temps de review	Qualité
Petite	< 200	15-30 min	Excellente
Moyenne	200-500	30-60 min	Bonne
Grande	> 500	> 1h	Médiocre

Visez des PR de moins de 200 lignes. Au-delà, découpez en plusieurs PR dépendantes.

La draft PR

Si votre travail n’est pas terminé mais que vous voulez un retour précoce, ouvrez une draft PR :

GitHub : bouton « Create draft pull request »
GitLab : préfixez le titre avec Draft: ou cochez l’option

La draft PR signale aux reviewers que le code n’est pas prêt pour le merge mais que des retours sont bienvenus sur l’approche.

Faire une revue de code

Ce que chercher

Catégorie	Points à vérifier
Logique	Le code fait-il ce qu’il prétend ? Cas limites ?
Lisibilité	Noms clairs ? Structure compréhensible ?
Tests	Couvrent-ils les cas importants ?
Sécurité	Injection, XSS, secrets en dur ?
Performance	Requête N+1, boucle coûteuse ?
Conventions	Style du projet respecté ?

Rédiger des commentaires constructifs

Les commentaires de review doivent être précis, bienveillants et actionnables :

Au lieu de…	Écrivez…
« C’est nul »	« Cette approche risque X. Et si on faisait Y ? »
« Pourquoi t’as fait ça ? »	« Quelle est la raison de ce choix ? Je me demande si Z serait plus maintenable. »
« Change ça »	« Suggestion : renommer `data` en `userProfile` pour plus de clarté. »

Les niveaux de commentaire

Préfixez vos commentaires pour indiquer leur importance :

nit: — détail cosmétique, non bloquant
suggestion: — idée d’amélioration, discutable
question: — demande de clarification
concern: — point potentiellement problématique
(pas de préfixe) — changement requis avant merge

Stratégies de merge

Au moment du merge, trois options s’offrent à vous :

Stratégie	Résultat	Avantage	Inconvénient
Merge commit	Commit de merge + historique complet	Traçabilité exacte de la PR	Graphe en losange, `git log` plus difficile à lire
Squash and merge	Un seul commit sur `main`	Historique de `main` très propre	Perd le détail des commits de la PR
Rebase and merge	Commits rejoués linéairement sur `main`	Historique linéaire avec commits individuels	Les hashes changent, attribution des auteurs peut varier

Le piège fréquent est de mélanger les stratégies : certaines PR sont squashées, d’autres mergées avec un commit de fusion, d’autres encore rebasées. L’historique de main devient alors illisible.

Recommandation : choisissez une seule stratégie et configurez-la comme défaut dans les paramètres du dépôt (GitHub : Settings → General → « Allow … merge », GitLab : Settings → Merge Requests).

Squash : recommandé pour les équipes qui veulent un git log lisible sur main (une ligne par fonctionnalité) et dont les commits intermédiaires sont des WIP
Merge commit : recommandé quand la traçabilité fine des commits est importante (audit, régression via git bisect)
Rebase : recommandé quand vous voulez des commits atomiques sur main sans commits de merge, mais que chaque commit de la PR est déjà propre et significatif

Protéger la branche principale

Configurez des règles de protection sur main :

Revue obligatoire : au moins 1 (ou 2) approbation(s) avant merge
CI/CD passante : les tests doivent être verts
Branche à jour : la branche doit être rebasée sur main
Pas de push direct : tout passe par une PR

Sur GitHub : Settings → Branches → Branch protection rules. Sur GitLab : Settings → Repository → Protected branches.

Dépannage : problèmes courants

Symptôme	Cause probable	Solution
PR avec conflits	Branche pas à jour avec `main`	`git rebase origin/main` puis force-push
« CI failed » sur la PR	Tests cassés ou linting	Corrigez localement, poussez un nouveau commit
Reviewer ne répond pas	PR trop grosse ou mal décrite	Découpez, améliorez la description, relancez poliment
Historique pollué de « fix review »	Commits de correction post-review	`git rebase -i` pour squasher avant merge

À retenir

Une PR = un sujet, de préférence < 200 lignes
Titre conventionnel (feat:, fix:, docs:) + description structurée
La draft PR permet d’obtenir un retour précoce
Les commentaires de review sont précis et bienveillants
Protégez main : revue obligatoire + CI passante
Choisissez une stratégie de merge cohérente dans l’équipe

Prochaines étapes

Workflows Git Gitflow, Feature Branch, Trunk-Based : comparez les stratégies.

Maintenir un projet Accepter les contributions et préparer des releases.

Réécrire l'historique Nettoyez vos commits avant d'ouvrir une PR.