Trois façons de combiner des branches. Chacune réécrit l'historique différemment.
Choisis la mauvaise et tu passeras une heure à démêler des commits. Choisis la bonne et ton git log reste propre.
Le contexte
Tu as deux branches : main et feature. Elles ont divergé.
Main a avancé. Feature a ses propres commits. Maintenant tu veux les réunir.
Trois options.
Merge
Le plus simple. Git crée un nouveau commit qui a deux parents.
git switch main
git merge feature
Le merge commit lie les deux historiques. Rien n'est réécrit. Tous les commits originaux restent exactement où ils sont.
Avantages :
- Safe. Pas de réécriture d'historique.
- Trace claire de quand les branches ont fusionné.
- Marche même si d'autres bossent sur la même branche.
Inconvénients :
- Crée des merge commits en plus.
- L'historique peut devenir bordélique avec beaucoup de branches.
TIP
Utilise merge quand tu travailles sur des branches partagées ou quand tu veux préserver l'historique exact de comment le travail s'est passé.
Rebase
Rebase prend tes commits et les rejoue par-dessus une autre branche. Comme si t'avais jamais branché.
git switch feature
git rebase main
Avant :
Après :
Les commits 5 et 6 deviennent 5' et 6'. Nouveaux hash, nouveaux parents, mais mêmes changements.
Avantages :
- Historique linéaire. Pas de merge commits.
- Plus facile à lire dans git log.
- Plus propre pour la code review.
Inconvénients :
- Réécrit l'historique. Les commits originaux disparaissent.
- Dangereux sur les branches partagées.
- Peut créer des conflits plusieurs fois (une fois par commit).
WARNING
Ne rebase jamais des commits que d'autres ont déjà pull. Tu vas créer des commits en double et embrouiller tout le monde.
🔍 Ce que "rejouer" veut vraiment dire
Quand tu rebase, Git :
- Trouve l'ancêtre commun des deux branches
- Sauvegarde tous tes commits comme des patches (diffs)
- Reset ta branche sur la branche cible
- Applique chaque patch un par un
C'est pour ça que les conflits peuvent arriver plusieurs fois. Chaque patch est appliqué séparément. Et c'est pour ça que les commits ont de nouveaux hash, ils ont des parents différents maintenant.
Squash
Squash c'est pas une commande séparée. C'est une option pendant un merge ou un rebase.
Ça prend plusieurs commits et les combine en un seul.
Squash merge
git switch main
git merge --squash feature
git commit -m "Add login feature"
Tous les changements de la branche feature deviennent un seul commit sur main. Les commits individuels (5, 6) disparaissent de l'historique de main.
Rebase interactif avec squash
git rebase -i HEAD~3
Ça ouvre ton éditeur :
pick a1b2c3d Add login form
pick b2c3d4e Add validation
pick c3d4e5f Fix typo
Change en :
pick a1b2c3d Add login form
squash b2c3d4e Add validation
squash c3d4e5f Fix typo
Les trois commits deviennent un. On te demandera un nouveau message de commit.
TIP
Utilise fixup au lieu de squash si tu veux jeter les messages de commit et garder seulement le premier.
Quand utiliser quoi
| Situation | Utilise |
|---|---|
| Merger une branche partagée (develop → main) | Merge |
| Mettre à jour ta feature branch avec main | Rebase |
| Nettoyer des commits bordéliques avant une PR | Squash (rebase interactif) |
| Merger une feature avec plein de petits commits | Squash merge |
| Travailler à plusieurs sur la même branche | Merge uniquement |
| Travail solo, historique propre important | Rebase |
La règle d'or
"Ne rebase pas l'historique public."
Si les commits existent seulement sur ta machine, rebase autant que tu veux. Dès que tu push et que quelqu'un d'autre a pu pull, stop. Utilise merge.
# Safe : rebase avant le premier push
git rebase main
# Dangereux : rebase après push
git push
# ... le temps passe, d'autres pull ...
git rebase main # NON
Gérer les conflits
Les trois méthodes peuvent créer des conflits. La résolution est la même :
- Git s'arrête et te dit quels fichiers sont en conflit
- Ouvre les fichiers, cherche les marqueurs de conflit :
<<<<<<< HEAD
ton code
=======
leur code
>>>>>>> feature
- Édite le fichier pour garder ce que tu veux
- Marque comme résolu :
# Pour merge
git add <fichier>
git commit
# Pour rebase
git add <fichier>
git rebase --continue
NOTE
Pendant un rebase, tu peux résoudre le même conflit plusieurs fois (une fois par commit rejoué). C'est normal mais chiant. Utilise git rerere pour automatiser les résolutions répétées.
🔍 Configurer rerere
git config --global rerere.enabled true
Git se souviendra comment tu as résolu les conflits et appliquera automatiquement la même résolution la prochaine fois.
Abandonner si ça part en vrille
T'as merdé ? Annule tout.
# Annuler un merge en cours
git merge --abort
# Annuler un rebase en cours
git rebase --abort
Tu reviens là où t'étais au départ.
Cheat sheet
| Commande | Ce qu'elle fait |
|---|---|
git merge feature | Merge avec merge commit |
git merge --squash feature | Squash tous les commits en un |
git rebase main | Rejoue les commits par-dessus main |
git rebase -i HEAD~n | Rebase interactif des n derniers commits |
git merge --abort | Annuler le merge |
git rebase --abort | Annuler le rebase |
git rebase --continue | Continuer après résolution de conflit |
Ce qu'il faut retenir
- Merge = safe, préserve l'historique, crée des merge commits
- Rebase = historique propre, réécrit les commits, dangereux sur branches partagées
- Squash = combine plusieurs commits en un
Y'a pas de réponse universellement correcte. Les équipes choisissent des conventions et s'y tiennent. Ce qui compte c'est que tout le monde soit d'accord.
Prochain article : résoudre les conflits en détail. Ce que les marqueurs veulent dire, les stratégies pour les conflits complexes, et les outils qui facilitent la vie.
C'est la partie 3 de ma série "Git & GitHub en 10 articles".
Des questions ? Contacte-moi sur LinkedIn ou découvre plus sur mon blog.