Workflow Git : guide des feature branches et pull requests

Un bon git workflow est l'investissement le moins cher que l'on puisse faire dans le code d'une équipe. Seul, pousser tout directement sur main ne pose aucun problème ; mais dès que deux personnes touchent au même fichier, la question de qui a changé quoi et quand reste sans réponse. Un flux fondé sur les feature branches et les pull requests existe précisément pour éviter ce chaos : chaque travail évolue sur sa propre branche, et la branche principale ne casse jamais avant que quiconque ait vu le changement.

Dans ce guide, je décris un flux simple mais discipliné qui fonctionne pour tout type d'équipe, des projets de serveur Metin2 aux applications web Laravel. Le but n'est pas de mémoriser des commandes tape-à-l'œil, mais de travailler en sachant ce que l'on fait et pourquoi.

Pourquoi une feature branch ?

La branche principale (main ou master) doit toujours être livrable. Tout ce que vous en extrayez doit pouvoir se construire et s'exécuter. Pour protéger cela, il faut tenir le travail inachevé hors de la branche principale. Chaque nouvelle fonctionnalité, correction de bug ou expérimentation vit sur sa propre branche :

• La branche principale reste intacte ; la production peut en être déployée à tout moment.
• Deux personnes travaillant en parallèle ne voient jamais le code à moitié écrit de l'autre.
• Si une fonctionnalité est annulée, supprimer la branche suffit ; aucune trace ne reste sur main.
• Chaque branche est un ensemble de changements autonome, révisable indépendamment.

Créer et nommer une branche

Avant de commencer, mettez à jour la branche principale, puis créez une nouvelle branche à partir d'elle. Dans Git moderne, c'est une seule commande :

git switch main
git pull --ff-only
git switch -c feature/connexion-utilisateur

git switch -c crée la branche et bascule dessus ; l'ancien git checkout -b fait la même chose. Utiliser un préfixe cohérent dans les noms de branches montre instantanément le type de travail lorsqu'on parcourt la liste :

• feature/ — une nouvelle fonctionnalité
• fix/ — une correction de bug
• chore/ — dépendances, configuration, nettoyage
• refactor/ — réorganisation interne qui ne change pas le comportement

Gardez le nom court mais parlant : fix/login-csrf, feature/payment-webhook. S'il y a un numéro d'issue, ajoutez-le : feature/142-pdf-export.

Discipline de commit

Un commit doit décrire un seul changement logique. « Tout dans un seul commit » et « un commit séparé pour chaque ligne » sont les deux extrêmes à éviter. Un bon message répond au pourquoi plutôt qu'au quoi, car le « quoi » est déjà visible dans le diff :

git add app/Http/Controllers/AuthController.php
git commit -m "fix: rediriger vers login au lieu de 419 quand la session expire"

Le format Conventional Commits (feat:, fix:, chore:, docs:) est à la fois lisible et facilite la génération automatique de changelog. Gardez la première ligne entre 50 et 72 caractères et, si nécessaire, ajoutez des détails après une ligne vide. Évitez de committer du code inachevé qui ne compile pas ; si vous avez réellement besoin d'une sauvegarde intermédiaire, utilisez git stash ou un commit « WIP » marqué, puis nettoyez plus tard avec git rebase.

Garder la branche à jour : merge ou rebase ?

Pendant que vous travaillez sur votre branche, la branche principale avance. Il y a deux façons de mettre votre branche à jour. Le merge intègre les changements de main dans votre branche et laisse un commit de fusion ; l'historique est honnête mais paraît emmêlé. Le rebase rejoue vos commits comme s'ils avaient commencé au sommet du dernier main ; l'historique reste plat et lisible.

git switch feature/connexion-utilisateur
git fetch origin
git rebase origin/main

La règle pratique : rebasez librement pour nettoyer l'historique d'une branche locale que vous n'avez pas encore partagée. Mais ne rebasez pas une branche que d'autres ont déjà tirée pour ensuite la pousser en force (--force) — cela corrompt l'historique de vos collaborateurs. Dans ce cas, --force-with-lease est plus sûr, car il refuse de pousser si quelque chose a changé depuis l'état que vous avez vu pour la dernière fois.

La pull request : votre changement rendu visible

Quand la branche est prête, poussez-la sur le dépôt distant et ouvrez une pull request (PR) :

git push -u origin feature/connexion-utilisateur

La PR est l'endroit où le code est discuté avant la fusion. Une bonne PR est petite — les changements de moins de 400 lignes sont nettement mieux révisés, car le relecteur peut tout garder en tête. La description devrait inclure :

• Ce qui a changé et pourquoi : une phrase de contexte suffit souvent.
• Comment cela a été testé : une capture d'écran, une sortie de commande ou des étapes de test.
• Un lien vers l'issue concernée (p. ex. Closes #142).

Les vérifications automatiques (CI) — tests, linter, build — devraient s'exécuter sur la PR. Ne fusionnez pas tant que ce n'est pas vert. Cela élimine en grande partie le problème du « ça marchait sur ma machine ».

Revue de code et fusion

La revue n'est pas une barrière ; c'est une appropriation partagée. Le relecteur ne traque pas seulement les bugs — il interroge le nommage, les cas limites et la possibilité d'une solution plus simple. Les commentaires visent le problème, pas la personne ; « que se passe-t-il dans ce cas ? » préserve la collaboration mieux que « pourquoi as-tu fait ça comme ça ? ».

Une fois approuvé, choisissez une stratégie de fusion :

• Squash merge : réduit tous les commits de la branche en un seul commit propre. L'historique principal reste lisible ; c'est le choix par défaut pour la plupart des équipes.
• Merge commit : préserve tout l'historique de la branche. Bien pour de longues séquences de commits significatives.
• Rebase merge : ajoute les commits sur main sous forme plate, sans laisser de commit de fusion.

Après la fusion, supprimez la branche — à la fois en distant et en local. Les branches mortes qui s'accumulent rendent plus difficile la lecture de l'état réel du dépôt.

git switch main
git pull --ff-only
git branch -d feature/connexion-utilisateur
git push origin --delete feature/connexion-utilisateur

Questions fréquentes

Pousser directement sur main n'est-il jamais acceptable ?

Sur un petit projet solo, c'est très bien. Mais dès que plus d'une personne est impliquée, rendez la branche principale protégée et faites passer chaque changement par une PR. Cela impose à la fois la revue et le filet de sécurité de la CI.

Dois-je utiliser merge ou rebase ?

Les deux sont valides ; c'est une décision d'équipe. Un équilibre pratique : rebasez pour garder votre branche locale à jour et ranger les commits, et squash merge pour intégrer la PR dans main. Ne rebasez jamais en force une branche partagée.

Quelle taille doit avoir une PR ?

Aussi petite que possible. Qu'elle couvre une seule tâche logique. Si une fonctionnalité est grande, découpez-la en petites PR qui peuvent fusionner indépendamment ; la revue et le retour arrière en deviennent plus faciles.

Du mal à stabiliser le flux git de votre équipe ? Si vous avez besoin d'aide pour la stratégie de branches, la configuration de la CI et une culture de revue de code, contactez-moi — construisons ensemble un workflow simple adapté à votre projet.