Que sont les branches ?
Une branche dans Git est un pointeur léger vers un commit spécifique. Quand vous créez une branche, Git ne copie aucun fichier — il crée simplement un nouveau pointeur. Cela rend le branching quasi instantané, même dans les grands dépôts. Voyez les branches comme des chronologies parallèles : la branche main est votre chronologie stable, et les branches de fonctionnalité sont des chronologies alternatives où vous construisez et testez sans affecter le code en production.
Chaque dépôt Git commence avec une seule branche (généralement main ou master). À partir de là, le modèle de branching que vous adoptez détermine comment votre équipe collabore. Le reste de cette page couvre toutes les commandes nécessaires pour maîtriser ce workflow.
Créer et changer de branche
Trois commandes vous permettent de créer et de naviguer entre les branches. git branch gère les branches, git switch permet de passer de l'une à l'autre, et l'ancienne commande git checkout fait les deux (et plus encore).
git branch
git branch est la commande principale pour gérer les branches. Exécutez-la sans argument pour lister les branches locales, ajoutez un nom pour en créer une, ou utilisez -d pour supprimer une branche déjà fusionnée. Elle ne change jamais votre répertoire de travail — elle ne gère que les pointeurs.
git switch
Introduite dans Git 2.23, git switch est la commande dédiée au changement de branche. Utilisez git switch -c nom pour créer et basculer en une seule étape. Elle est plus claire que checkout car elle ne fait qu'une chose : passer d'une branche à l'autre.
git checkout (legacy)
Avant Git 2.23, git checkout était la seule façon de changer de branche. Elle fonctionne toujours et vous la verrez dans les anciens tutoriels, mais elle restaure aussi des fichiers et détache HEAD — ce qui la rend facile à mal utiliser. Pour changer de branche, préférez git switch.
Stratégies de merge
Une fois votre branche de fonctionnalité prête, vous devez l'intégrer. Git propose trois stratégies principales : le merge pour un historique fidèle, le rebase pour un historique linéaire, et le cherry-pick pour récupérer des commits individuels.
git merge
git merge intègre une branche dans une autre. Si les branches ont divergé, Git crée un commit de merge avec deux parents — préservant l'historique complet. S'il n'y a pas de divergence, Git effectue un fast-forward merge (pas de commit supplémentaire nécessaire).
git rebase
git rebase prend chaque commit de votre branche et le rejoue par-dessus une autre branche. Le résultat est un historique parfaitement linéaire sans commits de merge. C'est puissant mais cela réécrit les hash des commits — ne rebasez donc jamais des commits qui ont été poussés sur une branche partagée.
git cherry-pick
git cherry-pick copie un seul commit d'une branche vers une autre. Il ne fusionne pas et ne rebase pas — il crée un nouveau commit avec les mêmes modifications. Utilisez-le quand vous avez besoin d'un correctif spécifique sans récupérer une branche entière.
Merge vs Rebase : lequel choisir ?
C'est l'un des débats les plus courants sur Git. Utilisez les cartes de décision ci-dessous pour choisir la bonne stratégie, puis consultez le tableau comparatif plus bas pour une vue d'ensemble.
Vous voulez un historique complet
La branche a été poussée ou partagée avec d'autres. Vous voulez que le travail de chaque contributeur reste visible dans le log. Les commits de merge servent de jalons montrant quand les fonctionnalités ont été intégrées.
Vous voulez un historique propre et linéaire
La branche est locale et n'a pas été poussée. Vous voulez une ligne droite de commits sans noeuds de merge. Le rebase garde le log facile à lire et rend git log --oneline agréable.
Vous avez besoin d'un seul commit
Un correctif critique se trouve sur une autre branche et vous n'avez besoin que de ce seul commit. Cherry-pick évite de récupérer du travail non lié. Idéal pour les hotfixes et les rétroportages.
La branche est partagée
Si vous avez déjà poussé votre branche et que d'autres travaillent dessus, le rebase réécrit l'historique et crée des commits divergents. Cela mène à la confusion et au travail en double. Utilisez merge à la place.
Gérer les conflits de merge
Un conflit de merge survient quand deux branches modifient la même ligne du même fichier. Git s'arrête et marque le fichier avec les marqueurs <<<<<<<, =======, >>>>>>>. Ouvrez le fichier, choisissez la version que vous souhaitez (ou combinez les deux), supprimez les marqueurs, puis ajoutez et commitez. Pour un guide détaillé, consultez notre page sur la résolution des conflits de merge.
Conventions de nommage des branches
Des noms de branches cohérents rendent votre dépôt plus facile à naviguer. La plupart des équipes utilisent un schéma préfixe/description. Voici les préfixes les plus courants :
| Préfixe | Objectif | Exemple |
|---|---|---|
| feature/ | Nouvelle fonctionnalité ou amélioration | feature/user-auth |
| bugfix/ | Correction de bug (non urgent) | bugfix/login-redirect |
| hotfix/ | Correctif urgent en production | hotfix/security-patch |
| release/ | Préparation de version | release/v2.1.0 |
| chore/ | Maintenance ou outillage | chore/update-deps |
Utilisez des lettres minuscules, des tirets au lieu d'espaces, et gardez les noms courts mais descriptifs. Un bon nom de branche indique à vos collègues ce sur quoi vous travaillez en un coup d'oeil.