Travailler en équipe : branches et pull requests
Résumé : dans une équipe qui utilise Git, personne ne touche directement à la branche principale. Chaque changement passe par une branche de fonctionnalité (feature branch), une pull request relue par au moins un collègue, et une fusion contrôlée. Cette leçon détaille les cinq étapes de ce workflow — utilisé chez 95 % des équipes tech modernes.
1. La règle d'or : la branche principale est sacrée
Sur un projet en équipe, la branche main (ou master sur les anciens dépôts) doit toujours être dans un état déployable. À tout moment, on doit pouvoir lancer un déploiement en production depuis cette branche sans risquer de casser quoi que ce soit.
Cette discipline se met en place par convention (accord d'équipe), et se verrouille techniquement sur GitHub/GitLab avec les branch protection rules (règles de protection de branche). Impossible alors de pousser directement sur main, même par accident.
2. Le workflow feature branch, en cinq étapes
C'est le workflow standard en 2026, adopté par Google, Meta, Netflix, Microsoft, et la quasi-totalité des startups. Il tient en cinq étapes.
Regardons chaque étape.
Étape 1 · Se synchroniser avec main
Avant de commencer, on récupère les derniers changements de main. Sinon, on risque de travailler sur une base obsolète et de créer des conflits inutiles.
Étape 2 · Créer une branche dédiée
On donne à la branche un nom explicite. Les conventions varient, mais un modèle courant est :
| Préfixe | Utilisation | Exemple |
|---|---|---|
feature/ | Nouvelle fonctionnalité | feature/paiement-stripe |
fix/ | Correction de bug | fix/validation-courriel |
hotfix/ | Correction urgente en production | hotfix/faille-xss-login |
chore/ | Tâche technique sans impact utilisateur | chore/mise-a-jour-dependances |
docs/ | Modification de documentation | docs/guide-api-v2 |
Un nom clair fait gagner du temps à toute l'équipe : dans la liste des branches ouvertes, chacun comprend immédiatement de quoi il s'agit.
Étape 3 · Développer avec des commits fréquents
Sur la branche, on applique le cycle vu à la leçon 1 : éditer, indexer, commit, éditer, indexer, commit… Plusieurs fois par jour. Chaque commit reste local jusqu'à ce qu'on décide de pousser.
Étape 4 · Pousser et ouvrir la pull request
Quand la fonctionnalité est terminée (ou même « en cours mais je veux du feedback »), on pousse la branche et on ouvre une pull request — c'est le sujet de la section suivante.
Étape 5 · Relecture, discussion, fusion
Les collègues lisent le code, laissent des commentaires, demandent des ajustements. On corrige, on repousse, on répond aux remarques. Une fois validée, la PR est fusionnée dans main.
3. Qu'est-ce qu'une pull request, précisément ?
Une pull request (« PR » pour les intimes, « merge request » ou « MR » sur GitLab) est une demande formelle d'intégrer une branche dans une autre, avec un espace de discussion.
C'est la brique fondamentale du développement moderne en équipe. Presque aucun code n'entre en production sans passer par une PR.
Anatomie d'une bonne PR :
- Titre clair et court, souvent préfixé du type (
fix:,feat:). - Description qui explique pourquoi cette PR existe, ce qu'elle change, comment la tester.
- Petite taille : idéalement moins de 400 lignes modifiées. Au-delà, la qualité de la relecture chute drastiquement.
- Un seul objectif : une PR = une intention. Si vous corrigez un bug ET refactorez ET mettez à jour des dépendances, ouvrez trois PR séparées.
4. La revue de code — le vrai bénéfice caché
La partie discussion d'une PR est celle qui apporte le plus de valeur à long terme. Voici pourquoi.
Point souvent mal compris : la revue de code n'est pas là pour juger l'auteur, elle est là pour améliorer le code. Une bonne revue est bienveillante, constructive, et se pose des questions plutôt que d'imposer des solutions (« Que penses-tu de… ? » plutôt que « Il faut faire… »).
Bonnes pratiques côté auteur d'une PR :
- Répondre à tous les commentaires (par un correctif, ou par une explication).
- Ne pas prendre les remarques personnellement.
- Remercier les relecteurs — leur temps est précieux.
Bonnes pratiques côté relecteur :
- Regarder d'abord la description et les changements de haut niveau, puis les détails.
- Poser des questions, ne pas imposer.
- Signaler ce qui est bloquant (nice-to-have vs. must-fix).
- Approuver rapidement quand c'est bon — bloquer une PR une semaine casse l'élan.
5. La fusion — trois modes principaux
Quand la PR est approuvée, il faut la fusionner dans main. GitHub, GitLab et Bitbucket proposent tous trois modes de fusion, qui donnent un historique différent.
Recommandation en 2026 : la majorité des équipes web modernes utilisent squash and merge par défaut. Résultat :
- L'historique de
mainreste linéaire et lisible (un commit = une PR = une fonctionnalité). - Les commits intermédiaires de la branche (« wip », « oups », « fix typo ») disparaissent.
- Chaque fusion produit un commit propre avec le titre de la PR comme message.
merge commit reste utilisé pour les projets où l'historique granulaire est important (noyau Linux, PostgreSQL). rebase and merge est plus rare, réservé à ceux qui aiment un historique parfaitement linéaire.
6. Après la fusion — le nettoyage
Une fois la branche fusionnée, elle n'a plus de raison d'exister. La supprimer libère l'espace visuel dans la liste des branches et évite la confusion.
Les grandes plateformes ont une option « supprimer automatiquement la branche après fusion » qu'il faut activer une fois pour toutes dans les paramètres du projet.
Retenir en 30 secondes
- La branche
mainest sacrée : personne n'y touche directement. - Chaque changement passe par une feature branch au nom explicite (
feature/…,fix/…). - On ouvre une pull request pour demander la fusion, avec titre + description + tests + relecture.
- La revue de code détecte les bugs, forme les juniors, diffuse la connaissance. C'est le vrai trésor du workflow.
- La fusion se fait généralement en squash and merge pour garder un historique de
mainpropre. - Après fusion, on supprime la branche pour rester organisé.
Suivant : GitHub Flow vs GitFlow vs Trunk-based →