Introduction : Pourquoi la gestion des branches Git est essentielle
La gestion des branches dans Git est bien plus qu'une simple fonctionnalité technique — c’est un levier stratégique pour structurer la collaboration, fluidifier les cycles de développement, et surtout garantir un historique claire et fonctionnel.
Chez HexoTech, nous accompagnons nos clients à chaque étape du cycle de vie de leurs applications. Et dans cette démarche, maîtriser Git et les bonnes pratiques associées fait toute la différence. Nous recommandons notamment une organisation de projet et d'équipe autour du Gitflow
Travailler en branches : un pilier de l’agilité logicielle
Définition d’une branche
Une branche Git correspond à un historique pour un contexte donné. Nous retrouvons souvent 2 grands types de branches:
- Les branches permanentes :
- branche principale (main ou master) : contient les releases (tags) et correspond à la version la plus récente du projet
- branche de support de version : Contient des releases de support d'anciennes version du projet.
- Les branches temporaires :
- branche de développement : branches de travail d'ajout d'une fonctionnalité
- branche de correction : branches de travail de correction de bug
Les bénéfices organisationnels du travail en branches
Il y a de très nombreux avantages à travailler avec des branches sur un projet sous Git:
- Indépendance de développement : chaque développeur peut avancer sans bloquer les autres.
- Isolation des fonctionnalités : chaque fonctionnalité est développée et testée indépendamment.
- Facilite les revues de code : via des pull requests ou merge requests.
- Expérimentation sans risque : les branches jetables permettent de tester des idées.
- Intégration simplifiée : Les branches de travail sont merge dans la branche principale uniquement lorsque l'on en a besoin. Cela permet de développé en avance de phase des fonctionnalités et de les intégrer uniquement lorsque cela est nécessaire.
Le merge dans Git : comprendre les deux modes principaux
Merge Fast-Forward : quand et comment l’utiliser
Le merge fast-forward est utilisé lorsque la branche cible n’a pas évolué depuis la création de la branche source. Git avance simplement le pointeur de la branche principale jusqu’au dernier commit de la branche secondaire.
Exemple
git switch master git merge develop
Les gros avantages de ce cas de figure sont :
- Historique linéaire et simple à relire.
- Pas de commit de merge.
- Pas de conflit de merge.
Merge avec commit de merge : Branches parallèles
Lorsque les deux branches ont évolué en parallèle, Git crée un commit de merge. Cela permet de préserver l’arborescence de la branche initiale tout en lui ajoutant l'arborescence de la branche cible. Le nouveau commit a alors 2 parents.
Exemple
git switch master git merge develop
Contrairement au cas du Fast Forward, nous avons ici un commit de merge qui contient les résolutions de conflits potentiels. L'historique est moins simple à relire mais conserve l'information du moment ou les 2 branches sont merges.
Le rebase dans Git : réécrire proprement l’histoire
Fonctionnement du rebase de base
Le rebase rejoue branche à la suite d'une branche cible. Il réécrit l’historique en créant de nouveaux commits.
Exemple :
git switch develop git rebase master
Cela permet d'avoir à la fin un historique linéaire. En effet, le rebase de develop à la suite de master place les branches en position de Fast Forward. Il est alors possible de merge dans master la branche develop sans créer de commit de merge.
Réécrire sont historique avec un rebase interactif
Il est possible de rebase une branche et au passage de réécrire sont historique. Pour cela il faut ajouter l'option -i. Cela permet notamment de fusionner les commits d'une branche de travail une fois le développement terminé: squash
Exemple :
git switch develop git rebase -i master
Merge vs Rebase : quel outil choisir ?
Le merge permet de conserver l'historique des modifications et de l'organisation. Nous voyons très clairement quand les branches on dérivées et quand elles on étés merge. En revanche l'historique peut très rapidement devenir complexe à relire et a comprendre.
Le rebase + merge à pour avantage d'avoir un historique plus linéaire, comme si, les développements étaient fait les uns après les autres.
Il n'y a pas de solution meilleur d'une autre. Le code source sera le même, seul l'historique changera. Il faut donc utiliser la méthode qui correspond le plus à votre besoin. Il faut tout de même garder en tête une chose importante. Lors du merge dans la branche principale d'une fonctionnalité il y aura potentiellement un conflit a résoudre:
- Dans le cas d'un commit de merge, ce sera l'intégrateur qui devra résoudre le conflit. Il n'est pas forcément le mieux placé pour cela
- Dans le cas du rebase + merge, c'est le développeur qui résoudra les conflits lors du rebase. Le merge se fera en Fast Forward, il sera alors sans conflit pour l'intégrateur
Chez HexoTech nous vous recommandons de privilégier le rebase + merge pour les branches de temporaires (feature et bugfix). Nous vous recommandons même un squash des commit de cette branche de travail afin d'avoir un historique linéaire mais surtout composé de commits claires et constructifs.
Pour aller plus loin:
- Notre article sur l'organisation d'équipe autour du gitflow
- Notre formation complète sur Git et Gitlab
FAQ – Tout ce que vous vous demandez sur merge et rebase
Est-ce que le rebase remplace totalement le merge ?
Non. Le rebase réécrit l’historique à la suite d'une branche, le merge garde la traçabilité. Les deux ont leur place selon le contexte.
Peut-on rebase la branche principale ?
Déconseillé. Cela complique la synchronisation des autres développeurs. La branche principale ne devrait jamais être réécrite, seulement enrichie
Faut-il toujours éviter les commits de merge ?
Non. Ils sont utiles pour visualiser les décisions et les fusions en équipe.
Que faire si un rebase échoue ?
Utiliser git rebase --abort pour revenir en arrière ou git rebase --continue après avoir résolu les conflits.
Comment nettoyer l’historique Git avant un push ?
Utilisez git rebase -i pour combiner, renommer ou supprimer des commits inutiles.
Peut-on mélanger merge et rebase dans un projet ?
Oui, tant que c’est fait de manière cohérente et maîtrisée.
Comment se former aux branches Git ?
Vous pouvez faire une demande de formation Git HexoTech
