Votre branche de fonctionnalité est en retard sur main et vous avez besoin du nouveau travail. Git merge vs rebase est le choix entre deux façons de l’obtenir, et les deux sont correctes. Elles diffèrent par l’aspect de l’historique ensuite.

Nous avons créé un petit dépôt, exécuté les deux commandes et collé les vraies sorties ci-dessous, pour que vous compariez le résultat au lieu de l’imaginer. Débutant avec Git ? Commencez par notre tutoriel Git pour débutants (en anglais).

Ce que font git merge et git rebase

git merge prend les sommets de deux branches et les combine. Si les deux ont de nouveaux commits, Git crée un commit de fusion à deux parents. Rien de ce qui existe déjà n’est modifié.

git rebase prend les commits propres à votre branche, les met de côté, déplace votre branche au sommet de l’autre puis les rejoue un par un. Les commits rejoués sont de nouveaux commits avec de nouveaux hash, même si leurs changements sont identiques.

Git merge en pratique

Notre point de départ : le commit A sur main, deux commits (F1, F2) sur feature, et un commit de plus (M1) ajouté ensuite à main. Nous fusionnons maintenant main dans feature.

git switch feature
git merge main
git log --oneline --graph

*   f507aab Merge main into feature
|\
| * 8842fb5 M1
* | 082cc6a F2
* | 5a71e3c F1
|/
* 8766865 A

Le graphe montre la vraie histoire : deux lignes de travail réunies. Les commits d’origine F1 et F2 gardent leurs hash. Le coût est un commit de fusion supplémentaire et, sur un projet actif, le graphe devient une toile d’araignée.

Git rebase en pratique

Même point de départ, mais cette fois nous faisons un rebase de feature sur main.

git switch feature
git rebase main
git log --oneline --graph

* 1ff474b F2
* bf9149e F1
* 8842fb5 M1
* 8766865 A

L’historique forme une ligne droite, comme si vous aviez commencé après M1. Regardez les hash : F1 était 5a71e3c et devient bf9149e, et F2 passe de 082cc6a à 1ff474b. Git les a réécrits, et c’est pourquoi le rebase demande de la prudence.

Merge vs rebase côte à côte

La règle d’or du rebase

Ne faites pas de rebase sur des commits qui existent hors de votre dépôt. Après un rebase, votre branche ne correspond plus à la copie du serveur, donc l’envoi exige un push forcé. Si un collègue a construit du travail sur les anciens commits, son historique diverge maintenant du vôtre, et le démêler est pénible.

Faire un rebase de votre branche de fonctionnalité privée est correct. Le faire sur main ou sur toute branche utilisée par d’autres, non.

Un flux de travail d’équipe sûr

Cette routine garde un historique propre sans surprendre personne. C’est aussi ce que la plupart des équipes utilisent avant leur pipeline CI, comme celui de notre guide GitHub Actions CI/CD (en anglais).

git switch feature
git fetch origin
git rebase origin/main        # or: git pull --rebase
# fix conflicts, then: git add <file> && git rebase --continue
git push --force-with-lease   # only on your own branch

--force-with-lease refuse d’écraser la branche du serveur si quelqu’un y a poussé depuis votre dernier fetch, ce qu’un simple --force détruirait en silence. Quand la pull request est approuvée, fusionnez-la dans main.

Comment annuler un mauvais rebase

Un rebase paraît destructeur, mais les anciens commits restent un temps dans le reflog de Git, vous pouvez donc revenir en arrière.

git reflog                    # find the commit before the rebase
git reset --hard HEAD@{5}     # example position, check reflog first

Créez une branche de sauvegarde avec git branch backup avant tout rebase risqué et la récupération tient en une commande. Vous lancez une base de données ou des outils dans des conteneurs ? Voir notre tutoriel Docker pour débutants (en anglais).

Pour conclure

Merge garde la vérité, rebase la garde propre. Utilisez rebase pour rafraîchir votre propre branche, merge pour la livrer, et ne réécrivez jamais un historique dont d’autres dépendent.

Questions fréquentes

Pour aller plus loin (articles en anglais)