Branche de rebase Git : comment rebaser en toute sécurité, étape par étape

Pour rebaser une branche, récupérez-la, basculez-y et relisez-la sur la nouvelle base : `git fetch origin`, `git switch topic`, `git rebase origin/main`. Git met de côté les propres commits de votre branche, déplace la branche jusqu'à la pointe de origin/main, puis réapplique les commits un par un. L'historique reste une ligne droite sans validation de fusion. Chaque commit rejoué reçoit un nouveau hachage, donc une branche que vous avez déjà poussée a besoin de git push --force-with-lease par la suite.

Que fait git rebase à une branche ?

Supposons que topic ait ses propres commits et que main en ait gagné trois depuis le démarrage de la branche. Le rebasage met à jour ce point de départ sans fusionner main dans votre branche :

# before
A---B---C---D---E   origin/main
     \
      F---G         topic

# after git rebase origin/main
A---B---C---D---E   origin/main
                 \
                  F'---G'   topic

F' et G' contiennent les mêmes modifications et messages que F et G, mais ce sont de nouveaux commits avec de nouveaux hachages, car leurs parents ont changé. Une fusion à partir du même point de départ conserverait les deux lignes et ajouterait un commit avec deux parents. La leçon sur fusion versus rebase montre les deux sur un seul graphique.

Comment rebaser une branche en toute sécurité, étape par étape ?

Inspectez d’abord, conservez l’ancienne astuce, rejouez, puis testez. Les trois premières commandes ne réécrivent rien :

# 1. update origin/main, your files stay as they are
git fetch origin

# 2. list the commits Git will replay
git log --oneline origin/main..topic

# 3. keep a name on the old tip
git branch topic-backup topic

# 4. replay
git switch topic
git rebase origin/main

Arrêtez-vous à l'étape 2 si la liste contient un commit que vous ne reconnaissez pas, car cela signifie que la branche n'a pas commencé là où vous le pensiez. Une fois le rebase terminé, exécutez git status pour confirmer qu'il est terminé, puis exécutez vos tests. Un rebase sans conflits peut toujours perturber le comportement.

Nommez la base à chaque fois. Un simple git rebase utilise l'amont de la branche, qui est souvent origin/topic et non main. Pour déplacer une branche démarrée à partir d'une autre branche de fonctionnalités, nommez également l'ancienne base : git rebase --onto main old-base topic. La leçon sur le rebasage de travaux non publiés met en pratique cela sur un vrai graphique.

Comment résoudre les conflits lors d’un rebase ?

Git applique vos commits un par un, afin qu'il puisse s'arrêter plusieurs fois, même dans les mêmes lignes. Corrigez uniquement le commit sur lequel Git s'est arrêté, puisque les derniers n'ont pas encore été appliqués :

# edit the file and remove the conflict markers, then
git add path/to/file
git rebase --continue

Si vous rejouez souvent le même conflit, git config rerere.enabled true enregistre votre résolution et la réutilise. Vérifiez chaque résultat réutilisé, car la réponse d’hier peut être fausse dans le code d’aujourd’hui. La leçon sur continuer, sauter et abandonner passe en revue chaque cas, et comment résoudre les conflits de fusion couvre la lecture des marqueurs.

Comment vérifier un rebase avant le push ?

Comparez l’ancienne série avec la nouvelle avant que quiconque ne la voie :

# old and new commits, matched pair by pair
git range-diff origin/main topic-backup topic

# everything the branch adds to main, as one diff
git diff origin/main...topic

# the shape of the history
git log --graph --oneline --decorate origin/main topic

git range-diff indique lorsqu'une résolution de conflit a modifié un correctif ou lorsqu'un commit a disparu. Le code qui compile peut toujours masquer un test abandonné ou une condition modifiée, et c'est ici que vous l'attrapez.

Comment annuler un rebase ?

Pendant qu'il est en cours d'exécution, utilisez git rebase --abort. Une fois terminé, remettez la branche vers l’ancienne pointe. Vérifiez d'abord git status, car --hard ignore les modifications non validées :

git reset --hard topic-backup

# no backup? find the old tip in the reflog
git reflog show topic
git reset --hard <old-tip-hash>

Le guide pour annuler une réinitialisation, un rebase ou un commit couvre le reflog plus en profondeur.

Comment faire un push après un rebase ?

Un push normal est refusé, car la branche distante contient toujours les anciens commits et Git voit une mise à jour sans avance rapide. Vérifiez ce que vous êtes sur le point de remplacer, puis lancez un bail :

git fetch origin
git log --oneline topic..origin/topic
git push --force-with-lease origin topic

Ce git log ne devrait répertorier que vos anciens commits. Tout le reste est le travail d’un coéquipier, alors arrêtez-vous et apportez-le en premier. --force-with-lease remplace la branche distante uniquement si elle se trouve toujours là où votre dernière récupération l'a vue, et --force n'a pas de vérification de ce type. Les récupérations en arrière-plan mettent à jour cette valeur, afin que les scripts puissent nommer le commit qu'ils attendent : git push --force-with-lease=topic:<expected-hash> origin topic.

Dois-je rebaser ou fusionner cette branche ?

Le guide pour rebaser une branche propose toutes les options, et forcer le push avec bail couvre le push. Pour écraser, reformuler ou réorganiser en cours de route, lisez rebase interactif dans une interface graphique.