Git rebase : rebase ou merge, rebase interactif et annulation

Guide de git rebase

Git rebase : rebase ou merge, rebase interactif, annulation | We.Inc

Comparez rebase et merge côte à côte sur un graphe de commits interactif, préparez un rebase interactif avec pick, squash, fixup et drop, et apprenez à interrompre ou annuler avec le reflog.

git rebase rejoue les commits de votre branche par-dessus un autre commit, ce qui donne un historique linéaire au lieu d'un commit de merge. Lancez git rebase main depuis votre branche de fonctionnalité, résolvez les éventuels conflits, puis git rebase --continue. Utilisez git rebase -i pour fusionner, renommer ou supprimer des commits, et git rebase --abort pour faire marche arrière.

Les commandes de rebase que vous taperez le plus

Objectif
Commande

Déplacer votre branche sur la dernière version de main
git rebase main

Modifier les 4 derniers commits
git rebase -i HEAD~4

Continuer après avoir résolu un conflit
git add <file> then git rebase --continue

Sauter le commit qui bloque
git rebase --skip

Annuler et revenir à l'état précédent
git rebase --abort

Intégrer automatiquement les commits fixup!
git rebase -i --autosquash main

Rebase est la commande git que l'on redoute le plus, surtout parce qu'elle réécrit des commits. Le graphe ci-dessous montre exactement ce qui change entre un merge et un rebase, le planificateur vous permet d'essayer un rebase interactif sur des commits d'exemple, et les dernières sections traitent des conflits, de la règle qui protège vos coéquipiers et de la façon de récupérer une branche après un rebase raté.

Basculez le graphe entre merge et rebase pour voir où atterrissent les commits et lesquels reçoivent de nouveaux hashes.
Dans le planificateur, changez l'action de chaque commit d'exemple et lisez la todo list que git ouvrirait ainsi que l'historique obtenu.
Copiez les commandes des tableaux dans votre propre terminal ; rien sur cette page n'exécute git à votre place.
Si un vrai rebase tourne mal, suivez la recette du reflog en bas de page pour restaurer l'ancienne pointe de la branche.

Commitez ou mettez de côté (stash) votre travail avant de commencer. Un rebase refuse de démarrer si l'arbre de travail contient des modifications.
Après avoir rebasé une branche déjà poussée, utilisez git push --force-with-lease plutôt que --force tout court, pour ne pas écraser les nouveaux commits d'un coéquipier.
Créez des commits de correction avec git commit --fixup <hash> au fil de votre travail, puis un seul git rebase -i --autosquash les range tous à la fin.
Activez git config --global rebase.autoStash true si vous oubliez souvent de faire un stash avant.

Questions fréquentes

Faut-il utiliser rebase ou merge ?

Merge conserve l'historique réel et ajoute un commit de merge, l'option la plus sûre pour les branches partagées. Rebase donne une ligne droite plus facile à lire et à parcourir avec bisect, ce qui convient à votre propre branche de fonctionnalité avant sa revue. Beaucoup d'équipes rebasent en privé et mergent en public.

Comment annuler un rebase ?

S'il est encore en cours, git rebase --abort remet tout en place. S'il est déjà terminé, lancez git reflog, trouvez l'entrée juste avant le début du rebase et faites git reset --hard vers ce hash. ORIG_HEAD pointe aussi vers l'ancienne pointe juste après un rebase, sauf si une autre commande l'a modifié.

Quelle est la règle d'or du rebase ?

Ne rebasez pas des commits sur lesquels d'autres personnes ont déjà basé leur travail. Le rebase crée de nouveaux commits avec de nouveaux hashes, donc toute personne qui détient les anciens se retrouve avec un historique en double et des conflits déroutants.

Quelle est la différence entre squash et fixup ?

Les deux fusionnent un commit dans celui du dessus. squash ouvre l'éditeur pour que vous combiniez les deux messages ; fixup jette le message du commit fusionné et garde le précédent. fixup -C garde plutôt le message du commit fusionné.

Pourquoi git rebase s'arrête sur un conflit ?

Chaque commit est réappliqué sur la nouvelle base, et un commit qui a touché les mêmes lignes que la base ne peut pas être appliqué automatiquement. Modifiez le fichier, faites git add, puis lancez git rebase --continue. Vous pouvez rencontrer un conflit pour chaque commit rejoué.

Ce que fait réellement rebase

Git trouve le commit où votre branche et la cible se sont séparées, enregistre vos commits sous forme de patchs, déplace votre branche sur la cible et applique les patchs un par un. Le résultat donne l'impression que vous avez commencé votre travail aujourd'hui à partir de la dernière version de main.
Comme chaque commit rejoué a un parent différent, il reçoit un hash différent. C'est pourquoi une branche rebasée nécessite un force push, et pourquoi rebaser un historique partagé pose problème.

Récupérer une branche avec le reflog

Le reflog enregistre, en local, chaque position vers laquelle HEAD et chaque pointe de branche ont pointé. Les commits écartés par un rebase restent accessibles par son intermédiaire, rien n'est donc perdu immédiatement.
Git élague les entrées du reflog lors du garbage collection : par défaut, les entrées accessibles après 90 jours et les inaccessibles après 30 jours. Rattrapez un mauvais rebase rapidement, pas des mois plus tard.

Commandes du rebase interactif

git rebase -i ouvre une todo list avec une ligne par commit, le plus ancien en haut. Changez le mot en début de ligne, enregistrez et fermez l'éditeur, et git exécute la liste de haut en bas.

Commandes de la todo list dans git rebase -i

Commande
Ce qu'elle fait

Garder le commit tel quel

Garder le commit mais modifier son message

S'arrêter après ce commit pour le modifier ou le scinder

Fusionner dans le commit du dessus et combiner les deux messages

Fusionner dans le commit du dessus et abandonner ce message

fixup -C
Fusionner dans le commit du dessus et utiliser le message de ce commit

Exécuter une commande shell, par exemple vos tests

Faire une pause ici ; reprendre avec git rebase --continue

Supprimer le commit

label / reset / merge
Nommer des points et reconstruire les merges (utilisé avec --rebase-merges)

Déplacer la référence d'une autre branche à ce point (utilisé avec --update-refs)

Un rebase complet, conflits compris

Mettre à jour une branche de fonctionnalité sur main

Faites d'abord un fetch pour que main soit à jour, rebasez, résolvez les conflits éventuels, puis poussez la branche réécrite en toute sécurité.

Annuler un rebase terminé avec le reflog

Trouvez la ligne juste avant le début du rebase et réinitialisez la branche à ce point.

Déplacer une branche sur une autre base

--onto prend trois points : la nouvelle base, l'ancienne base et la branche. Seuls les commits situés après l'ancienne base sont déplacés.

Détacher une branche d'une autre branche de fonctionnalité

feature-b a été créée à partir de feature-a. Cette commande place uniquement les commits propres à feature-b par-dessus main.

Ajout du formulaire de connexion
Correction d'une coquille dans le libellé du formulaire
Validation du champ e-mail
WIP sortie de débogage

Merge ou rebase : ce qui arrive à l'historique

Choisissez comment combiner les branches

Merge

Rebase

commit de merge

Merge laisse F1 et F2 intacts et ajoute un nouveau commit avec deux parents.

Rebase copie F1 et F2 sur M3. Les copies (marquées ') ont de nouveaux hashes ; les originaux sont laissés de côté.

Planificateur de rebase interactif

Choisissez une action pour chaque commit, du plus ancien au plus récent, et voyez la todo list et le résultat.

Action pour le commit {n}

Todo list ouverte par git

Historique après le rebase

La première ligne ne peut pas être squash ou fixup : aucun commit au-dessus ne peut l'accueillir.