Workflow par branche de fonctionnalité

Vue d'ensemble

Le workflow par branche de fonctionnalité est la façon la plus courante de collaborer avec Git en équipe. La règle est simple : tout le développement se fait sur des branches dédiées, jamais directement sur main. Chaque nouvelle fonctionnalité, correctif ou expérimentation reçoit sa propre branche, et la branche main ne reçoit que du travail finalisé et révisé. Cela garantit que main reste stable et déployable en permanence.

L'idée centrale

Comme le travail est isolé sur des branches, plusieurs personnes peuvent développer différentes fonctionnalités en parallèle sans se gêner. main joue le rôle de source de vérité unique pour le code prêt à être mis en production. Une branche est une unité de travail focalisée qui a un début précis (créée à partir de main) et une fin précise (fusionnée en retour dans main).

Point important : une branche dans Git est légère — c'est simplement un pointeur mobile vers un commit, et non une copie de vos fichiers. La créer est instantané et n'occupe presque pas d'espace disque, ce qui explique pourquoi créer une branche par tâche est parfaitement pratique.

Nommer les branches

Un schéma de nommage cohérent rend les branches auto-documentées. La plupart des équipes préfixent la branche selon son type et référencent la tâche en cours :

feature/login-form
feature/W3-142-checkout-page
fix/null-pointer-on-logout
chore/upgrade-eslint

Le slash n'est qu'une convention — Git traite feature/login-form comme un seul nom de branche, même si cela permet aux outils de regrouper les branches par préfixe. Évitez les espaces et les majuscules pour garder des noms faciles à saisir.

Un exemple pas à pas

Le workflow est une boucle courte et répétable : créer une branche depuis main, travailler, pousser, réviser, fusionner, nettoyer.

1. Créer la branche depuis un main à jour

Partez toujours du main le plus récent pour que votre branche soit basée sur le code actuel :

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

git switch -c crée la branche et la bascule en une seule étape (l'équivalent plus ancien est git checkout -b). Voir git switch pour la commande complète.

2. Effectuer le travail en commitant au fur et à mesure

Commitez par petites étapes logiques plutôt qu'en un seul gros commit à la fin — les petits commits sont plus faciles à réviser et à annuler :

git add login.html login.js
git commit -m "Add login form markup and validation"

Préférez indexer des fichiers spécifiques plutôt que git add . pour éviter de committer accidentellement des modifications sans rapport. En savoir plus sur la rédaction de bons commits dans git commit.

3. Pousser la branche

Poussez pour que vos coéquipiers puissent voir votre travail et pour pouvoir ouvrir une pull request. Le flag -u lie votre branche locale à la branche distante, de sorte que vous pourrez ensuite simplement taper git push :

git push -u origin feature/login-form

Voir git push pour le détail de ce que fait -u (--set-upstream).

Révision et fusion

Sur une plateforme d'hébergement comme GitHub ou GitLab, vous ouvrez une pull request (PR), appelée merge request sur GitLab. C'est là que les coéquipiers examinent le diff, laissent des commentaires et approuvent. Les vérifications d'intégration continue (CI) exécutent généralement la suite de tests sur la branche automatiquement. Une fois la PR approuvée et les vérifications au vert, la branche est fusionnée dans main.

Ces plateformes proposent trois stratégies de fusion courantes :

• Merge commit — conserve chaque commit de la branche ainsi qu'un commit de fusion. Préserve l'historique complet mais peut être verbose.
• Squash and merge — regroupe tous les commits de la branche en un seul commit propre sur main. Populaire car main reste propre et chaque fonctionnalité forme une seule entrée.
• Rebase and merge — rejoue les commits de la branche sur main sans commit de fusion, ce qui produit un historique linéaire.

Nettoyer après la fusion

Une fois la branche fusionnée, supprimez-la localement et à distance pour éviter que le dépôt ne se remplisse de branches obsolètes :

git switch main
git pull
git branch -d feature/login-form        # delete the local branch
git push origin --delete feature/login-form   # delete the remote branch

git branch -d refuse de supprimer une branche qui n'a pas encore été fusionnée, ce qui vous protège contre la perte de travail. (Utilisez -D pour forcer la suppression lorsque vous êtes certain.)

Maintenir une branche à jour

Si main avance pendant que vous travaillez, intégrez ces changements dans votre branche pour que la fusion finale se passe bien et que les conflits apparaissent tôt. Deux options s'offrent à vous :

# Option A — merge main into your branch (keeps history as-is)
git switch feature/login-form
git merge main

# Option B — rebase your branch onto the latest main (linear history)
git switch feature/login-form
git rebase main

La fusion (merging) est non-destructive et sûre pour les branches partagées, mais ajoute des commits de fusion. Le rebase produit un historique plus propre et linéaire, mais réécrit les commits de votre branche — évitez donc de rebaser une branche que d'autres ont déjà récupérée. La règle d'or : rebasez votre propre branche privée, fusionnez tout ce qui est partagé.

Gérer les conflits

Quand deux branches modifient les mêmes lignes, la fusion ou le rebase s'arrête et vous demande de résoudre le conflit. Git marque les zones conflictuelles dans les fichiers concernés ; vous les éditez, puis vous indexez et continuez. Le processus complet est décrit dans Résoudre les conflits de fusion.

Sauvegarder un travail en cours

Si vous devez changer de branche mais n'êtes pas prêt à committer, git stash met de côté vos modifications non commitées pour que vous puissiez vous déplacer librement et les restaurer plus tard :

git stash            # set current changes aside
git switch main      # do something urgent
git switch feature/login-form
git stash pop        # bring the changes back

Avantages et compromis

Le workflow par branche de fonctionnalité est populaire car il est facile à comprendre, s'intègre naturellement aux pull requests et à la revue de code, et maintient main déployable en permanence.

Son principal risque est celui des branches à longue durée de vie : plus une branche vit longtemps, plus elle diverge de main et plus la fusion finale devient difficile (le fameux « merge hell »). Pour l'éviter :

• Gardez les branches petites et éphémères — idéalement fusionnées en un ou deux jours.
• Intégrez main dans votre branche (ou rebasez) régulièrement, pas seulement à la fin.
• Découpez les grandes fonctionnalités en plusieurs branches plus petites qui fusionnent chacune indépendamment.
• Ne commitez jamais directement sur main — cela va à l'encontre du but du workflow.

Quand les équipes ont besoin de branches de release, de branches de hotfix et d'un processus de promotion strict par-dessus tout cela, elles adoptent souvent un modèle plus complet comme Git Flow ou le développement trunk-based — mais la branche de fonctionnalité est le bloc de construction qui sous-tend tous ces modèles.

Pratique