Quand tu veux ramener les changements d'une branche dans une autre, Git te propose deux outils : merge et rebase. Ils produisent des historiques différents, avec des avantages différents.
Merge : préserver l'historique réel
git merge prend les deux branches et crée un merge commit qui unit leurs histoires. Le graphe reste fidèle à la réalité : tu vois exactement quand la branche a divergé et quand elle a été intégrée.
Le résultat dans git log --graph ressemble à ceci : deux lignes parallèles qui se rejoignent en un seul point. C'est lisible, traçable, et non destructif.
Rebase : linéariser l'historique
git rebase rejoue tes commits sur la pointe d'une autre branche. Le résultat : un historique parfaitement linéaire, comme si tu avais toujours travaillé après les derniers commits de main.
Git déplace chaque commit de ma-feature un par un, en les réappliquant après le dernier commit de main. L'historique devient une ligne droite, sans merge commit.
Comparaison rapide
| Merge | Rebase | |
|---|---|---|
| Historique | Préservé, avec merge commit | Linéarisé, commits réécrits |
| Sûr sur branche partagée | Oui | Non |
| Lisibilité du graphe | Montre les vraies branches | Propre et linéaire |
Quand utiliser lequel
- Merge : pour intégrer une feature dans
main, pour garder une trace claire de ce qui vient d'où. C'est le choix par défaut dans un contexte collaboratif. - Rebase : pour nettoyer l'historique d'une branche locale avant d'ouvrir une pull request. Tu "rebases sur main" pour que ta PR s'applique proprement sur la dernière version du code.
Un workflow courant : tu travailles sur ma-feature, tu fais git rebase main pour te mettre à jour sans merge commit parasite, puis tu ouvres une PR. GitHub fusionne ensuite avec un merge commit officiel.