Merge ou rebase ? git rebase, squash et cherry-pick

git merge et git rebase intègrent tous deux le travail d'une branche dans une autre, mais pas de la même façon : merge réunit les deux historiques par un commit de fusion sans rien modifier, alors que rebase rejoue tes commits un par un au-dessus de l'autre branche et produit un historique linéaire, en créant de nouveaux commits. Ce chapitre explique quand choisir l'un ou l'autre, la règle qui évite les catastrophes, le rebase interactif pour nettoyer ses commits (squash, reword, fixup), git cherry-pick et le push forcé sans danger.

Ce que fait git rebase

Lina a créé feature/export à partir de main et y a fait deux commits, D et E. Pendant ce temps, Hugo a poussé le commit C sur main. Lina veut que sa branche parte du main actuel.

git switch feature/export
git rebase main

Successfully rebased and updated refs/heads/feature/export.

Git a mis de côté les commits D et E, déplacé le point de départ de la branche sur C, puis rejoué D et E par-dessus. Comme leur parent a changé, ce ne sont plus les mêmes commits : ils ont de nouvelles empreintes, notées D' et E'.

Si Lina fusionne ensuite sa branche dans main, l'avance rapide suffit : l'historique de main reste une ligne droite, sans commit de fusion.

Merge ou rebase : comparaison

Les deux donnent le même code à la fin. Le choix porte sur l'historique que tu veux lire ensuite, et sur la sécurité de l'équipe.

La règle d'or du rebase

Pourquoi ? Si Hugo a déjà récupéré tes commits D et E et a construit dessus, ton rebase les remplace par D' et E'. Pour Git, ce sont des commits différents. Au prochain pull de Hugo, son dépôt contient D, E, D' et E' : des doublons, des conflits sur des modifications déjà intégrées, et un historique incompréhensible.

Concrètement, dans un projet de BTS en équipe :

• rebase ta branche feature/… sur main tant qu'elle n'existe que chez toi, ou que tu es seul à la pousser ;
• ne rebase jamais main ni une branche sur laquelle un coéquipier travaille aussi ;
• en cas de doute, utilise git merge : il ne détruit rien.

Résoudre un conflit pendant un rebase

Le rebase rejoue les commits un par un. Si l'un d'eux entre en conflit, Git s'arrête sur ce commit :

Auto-merging config.js
CONFLICT (content): Merge conflict in config.js
error: could not apply 9e1c4a7... Fixe le plafond repas à 25
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".

Tu résous comme d'habitude (chapitre 6), puis :

git add config.js
git rebase --continue     # passe au commit suivant

git rebase --skip abandonne le commit en cours (s'il est devenu inutile), et git rebase --abort remet tout dans l'état d'avant le rebase. Pendant un rebase, tu es en HEAD détaché : c'est normal, la branche est replacée à la fin.

git pull --rebase

git pull récupère les commits du dépôt distant et les intègre à ta branche. Quand tu as commité de ton côté pendant que quelqu'un poussait, il y a deux façons d'intégrer : une fusion, qui ajoute à chaque pull un commit Merge branch 'main' of github.com:… qui n'apporte rien à la lecture, ou un rebase.

git pull --rebase rejoue plutôt tes commits locaux, pas encore poussés, au-dessus des commits récupérés. L'historique reste linéaire. C'est sans danger, puisque les commits rejoués n'ont encore été vus par personne. C'est ce que fait le réglage pull.rebase true proposé au chapitre 1.

Depuis 2021, si les deux historiques ont divergé et que tu n'as rien configuré, Git refuse de choisir à ta place :

hint: You have divergent branches and need to specify how to reconcile them.
hint: You can do so by running one of the following commands sometime before
hint: your next pull:
hint:
hint:   git config pull.rebase false  # merge
hint:   git config pull.rebase true   # rebase
hint:   git config pull.ff only       # fast-forward only
...
fatal: Need to specify how to reconcile divergent branches.

Choisis une fois pour toutes avec git config --global pull.rebase true (ou false si ton équipe préfère les fusions), et le message disparaît.

Nettoyer ses commits avec le rebase interactif

Avant de proposer ton travail, ta branche ressemble souvent à ceci :

a41f9e2 wip
c09d7b1 Ajoute l'export CSV des notes
7e2b8f3 oups faute de frappe
55c1a90 Ajoute les tests de l'export

Le rebase interactif permet de réécrire ces commits : les regrouper, les renommer, les réordonner, en supprimer. Pour retravailler les quatre derniers :

git rebase -i HEAD~4

Git ouvre l'éditeur avec la liste, du plus ancien au plus récent (l'inverse de git log) :

pick 55c1a90 Ajoute les tests de l'export
pick 7e2b8f3 oups faute de frappe
pick c09d7b1 Ajoute l'export CSV des notes
pick a41f9e2 wip

Tu remplaces pick par l'action voulue sur chaque ligne :

Tu peux aussi changer l'ordre des lignes. Pour obtenir deux commits propres, l'export puis ses tests :

pick c09d7b1 Ajoute l'export CSV des notes
fixup a41f9e2 wip
pick 55c1a90 Ajoute les tests de l'export
fixup 7e2b8f3 oups faute de frappe

Enregistre et ferme : Git rejoue la liste. Résultat, deux commits avec des messages clairs. Si un réordonnancement provoque un conflit, Git s'arrête comme pour un rebase normal.

Squash : un commit par fonctionnalité

Squash veut dire écraser : regrouper plusieurs commits en un seul. Tu le fais de trois façons :

• avec le rebase interactif et les actions squash ou fixup, comme ci-dessus ;
• avec git reset --soft vers le point de départ, puis un seul commit (chapitre 4) ;
• au moment de la fusion, avec git merge --squash ou le bouton Squash and merge d'une pull request (chapitre 9).

Regrouper n'est pas toujours souhaitable : trois commits qui racontent trois étapes distinctes (la migration de la base, la route, l'écran) valent mieux qu'un commit énorme. On regroupe les commits de bricolage (« wip », « oups »), pas les étapes.

Récupérer un commit précis avec git cherry-pick

Hugo a corrigé un bug d'arrondi sur sa branche feature/tableau-de-bord, qui ne sera pas fusionnée avant deux semaines. La correction est urgente pour main. git cherry-pick copie un commit d'une autre branche sur la branche courante :

git switch main
git cherry-pick 3b7e0d4

[main 8f21c6a] Arrondit le total au centime
 Date: Tue Oct 13 10:12:44 2026 +0200
 1 file changed, 1 insertion(+), 1 deletion(-)

Le nouveau commit a les mêmes modifications et le même message, mais une autre empreinte. Les options utiles : -x ajoute au message la ligne (cherry picked from commit 3b7e0d4…), pratique pour la traçabilité ; git cherry-pick A..B copie une série de commits (de A exclu à B inclus). À utiliser avec parcimonie : si la branche de Hugo est fusionnée plus tard, la même modification arrive deux fois, ce qui se passe bien en général, mais complique la lecture de l'historique.

Push forcé et force-with-lease

Après un rebase ou un --amend sur une branche que tu avais déjà poussée, l'historique local et l'historique distant ont divergé : GitHub refuse un push normal.

 ! [rejected]        feature/export -> feature/export (non-fast-forward)
error: failed to push some refs to 'github.com:ton-pseudo/sorbier-frais.git'

Si la branche est la tienne seule, tu peux forcer. Utilise toujours la forme prudente :

git push --force-with-lease

--force-with-lease te protège du cas où un coéquipier a poussé sur ta branche sans que tu le saches. Ne force jamais sur main ou sur une branche partagée : c'est ce que les règles de protection de branche interdisent.

Exercices

e5f6a7b Corrige une faute dans le message d'erreur
d4e5f6a wip validation
c3d4e5f Ajoute la validation du montant
b2c3d4e ajoute route
a1b2c3d Initialise l'API

reword b2c3d4e ajoute route
pick c3d4e5f Ajoute la validation du montant
fixup d4e5f6a wip validation
fixup e5f6a7b Corrige une faute dans le message d'erreur