Git rebase interactif : organiser ses commits avant de les partager

Comprendre ce que le rebase réécrit

Un rebase interactif Git rejoue une série de commits un par un et vous laisse décider du sort de chacun : le garder, reformuler son message, le fondre dans le précédent, le supprimer ou le déplacer. Git ne modifie jamais un commit existant. Il en crée de nouveaux, si bien que chaque commit rejoué reçoit un nouvel identifiant.

L’identifiant d’un commit est une empreinte de son contenu, et ce contenu inclut l’identifiant de son parent. Changez le parent, l’identifiant change, même si les fichiers sont identiques. Pro Git précise que chaque commit de l’intervalle est réécrit, que vous changiez son message ou non.

Les exemples utilisent un dépôt jetable nommé orbit-api. La branche feature/export porte trois commits locaux au-dessus de main, et vous l’avez poussée sur origin comme sauvegarde. Vos identifiants seront différents, car ils dépendent de l’auteur, de la date et du contenu.

git log --oneline --graph --decorate

* 7bfd3fa (HEAD -> feature/export, origin/feature/export) feat: add export progress events
* a98537c feat: stream large exports
* 0d50b71 feat: add CSV export endpoint
* 9fd61d6 (origin/main, main) chore: init orbit-api

L’objectif : fondre le deuxième commit dans le premier et donner un message plus clair au troisième.

Choisir les commits à retravailler

git rebase -i (--interactive) prend le commit situé juste avant le premier que vous voulez modifier. HEAD~3 désigne trois commits en arrière à partir du commit courant ; cette commande couvre donc les trois derniers commits :

git rebase -i HEAD~3

Vous pouvez aussi passer un nom de branche : git rebase -i main sélectionne tous les commits de votre branche depuis qu’elle a quitté main. Git ouvre votre éditeur avec une ligne par commit, le plus ancien en premier. C’est l’inverse de git log, car c’est l’ordre dans lequel Git les rejoue.

pick 0d50b71 feat: add CSV export endpoint
pick a98537c feat: stream large exports
pick 7bfd3fa feat: add export progress events

# Rebase 9fd61d6..7bfd3fa onto 9fd61d6 (3 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# …

J’ai produit les sorties avec Git 2.30, en pilotant les éditeurs avec GIT_SEQUENCE_EDITOR et GIT_EDITOR ; dans votre terminal, Git ouvre votre éditeur.

Dans GitMini, faites un clic droit sur un commit et choisissez Interactive rebase from here… pour démarrer à ce commit. Vous pouvez aussi faire un clic droit sur une autre branche pendant que la vôtre est la branche courante et choisir Interactive rebase of “feature/export” on “main”… ; cette base doit déjà appartenir à l’historique de votre branche, car GitMini réécrit les commits qui la suivent sans les déplacer sur un main plus récent (la boîte Rebase simple s’en charge).

La liste s’ouvre dans la zone centrale sous le titre Interactive rebase, du plus ancien commit au plus récent. Les deux entrées n’apparaissent que si HEAD est sur une branche (sinon le panneau affiche « The interactive rebase requires being on a branch. »). Le panneau refuse les plages qui contiennent des commits de fusion : « Range containing merges: not supported in v1. »

Utiliser pick, reword, squash et l’ordre des commits

Chaque ligne commence par une action. Changez ce mot, enregistrez, et Git exécute la liste de haut en bas.

Action	Effet	Libellé dans GitMini
`pick`	Garde le commit tel quel	pick — keep
`reword`	Garde le contenu, vous laisse modifier le message	reword — edit message
`squash`	Fond le commit dans le précédent et combine les deux messages	squash — merge (combined message)
`fixup`	Comme squash, mais abandonne le message de ce commit	fixup — merge (message ignored)
`drop`	Supprime le commit	drop — delete

Git connaît aussi edit, qui s’arrête pour que vous modifiiez un commit ; GitMini ne le propose pas. Réordonner ne demande aucun mot-clé : on déplace la ligne, comme le montre Pro Git. Le guide du réordonnancement va plus loin.

Pour l’exemple, transformez la liste ainsi :

pick 0d50b71 feat: add CSV export endpoint
squash a98537c feat: stream large exports
reword 7bfd3fa feat: add export progress events

Git ouvre d’abord un éditeur pour le commit regroupé, prérempli avec les deux messages. Remplacez-les par une seule ligne, ici feat: add streaming CSV export endpoint. Il ouvre ensuite l’éditeur pour la ligne reword, et le troisième message devient feat: emit progress events during export. Git affiche aussi un compteur Rebasing (n/m), omis ici :

[detached HEAD 10c3a07] feat: add streaming CSV export endpoint
…
[detached HEAD 2d3db63] feat: emit progress events during export
…
Successfully rebased and updated refs/heads/feature/export.

Le graphe montre maintenant les deux versions (--all garde la branche distante visible) :

git log --oneline --graph --decorate --all

* 2d3db63 (HEAD -> feature/export) feat: emit progress events during export
* 10c3a07 feat: add streaming CSV export endpoint
| * 7bfd3fa (origin/feature/export) feat: add export progress events
| * a98537c feat: stream large exports
| * 0d50b71 feat: add CSV export endpoint
|/
* 9fd61d6 (origin/main, main) chore: init orbit-api

Aucun nouveau commit ne partage son identifiant avec un ancien, alors que les fichiers sont les mêmes. L’ancien sommet reste accessible sous feature/export@{1}, et les deux empreintes d’arbre sont égales : le contenu final est identique.

git rev-parse 'feature/export@{1}^{tree}' 'feature/export^{tree}'

818593d01a34e4142e75d2be459e51852e6783b0
818593d01a34e4142e75d2be459e51852e6783b0

Pour un seul commit, corriger avec amend est plus court. Le guide de GitLab recommande le rebase interactif pour ranger votre propre historique local. Le regroupement est détaillé dans le guide du squash.

GitMini propose les mêmes choix dans un seul panneau :

Panneau Interactive rebase de GitMini listant trois commits de feature/export, le deuxième réglé sur squash, son message combiné dans un champ de texte et le résumé 3 commits → 2 commits — Chaque commit a un menu d’actions et une poignée de déplacement. Le commit regroupé affiche son message combiné, et le pied du panneau prévisualise le résultat avant de cliquer sur Launch rebase.

Une ligne squash ou fixup est décalée sous le commit qu’elle rejoint, et la dernière du groupe porte un champ de texte avec le message combiné. La poignée à gauche déplace un commit, et le pied du panneau prévisualise le nombre de commits, par exemple « 3 commits → 2 commits », avant le clic sur Launch rebase. GitMini refuse une liste qui commence par un squash (« The first commit cannot be merged with a previous commit. ») ou qui supprime tous les commits (« At least one commit must be kept. »).

Continuer ou annuler après un conflit

Un conflit interrompt le rejeu. Un commit de collègue, feat: add users route, arrive sur main et modifie la même ligne de src/app.ts que votre premier commit. Vous rebasez sur main en laissant la liste inchangée :

git rebase -i main

Auto-merging src/app.ts
CONFLICT (content): Merge conflict in src/app.ts
error: could not apply 10c3a07... feat: add streaming CSV export endpoint
Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
…
To abort and get back to the state before "git rebase", run "git rebase --abort".
Could not apply 10c3a07... feat: add streaming CSV export endpoint

Git 2.54 préfixe les lignes de conseil par hint: et écrit chaque sujet de commit après un #, comme dans la liste. Le rebase est en pause sur le premier commit. git status -sb liste UU src/app.ts, et le fichier contient les marqueurs de conflit :

<<<<<<< HEAD
export const routes = ["/health", "/users"];
=======
export const routes = ["/health", "/export"];
>>>>>>> 10c3a07 (feat: add streaming CSV export endpoint)

Vous avez trois issues. git rebase --abort ramène la branche là où elle était avant le début ; dans l’exemple, git log montre le sommet de retour à 2d3db63. git rebase --skip laisse de côté le commit en cours. Pour résoudre, gardez les deux routes dans le fichier, indexez-le et continuez (j’ai défini GIT_EDITOR=true pour que Git accepte le message sans ouvrir d’éditeur) :

git add src/app.ts
git rebase --continue

[detached HEAD 1d73c42] feat: add streaming CSV export endpoint
…
Successfully rebased and updated refs/heads/feature/export.

Quand un rebase s’arrête dans GitMini, le panneau se ferme et un bandeau nomme le rebase et le commit en cours d’application (« conflict by applying … »), avec le nombre de fichiers en conflit. Continue reste désactivé tant que vous n’avez pas résolu et indexé les fichiers (infobulle : « Resolve and stage the conflicting files »). Skip laisse de côté le commit en cours. Abort demande une confirmation, « Back to status before the rebase? Ongoing resolutions will be lost. », puis restaure la branche.

Vérifier le résultat avant de partager

Comparez l’ancien et le nouveau sommet : après un rebase sur un main qui a avancé, seul l’apport de main doit différer, ici la ligne de feat: add users route :

git diff --stat 'feature/export@{1}' feature/export

 src/app.ts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

J’utilise @{1} plutôt qu’ORIG_HEAD, qui ne pointe pas forcément sur l’ancien sommet à la fin d’un rebase ; la documentation de git-rebase renvoie au reflog de la branche. Le guide de lecture du graphe aide quand l’image se complique.

Dernière vérification : quelqu’un a-t-il vos anciens commits ? Ici, origin/feature/export les a toujours, et Git signale donc que les deux côtés ont divergé, avec trois commits différents de chaque côté.

git status

On branch feature/export
Your branch and 'origin/feature/export' have diverged,
and have 3 and 3 different commits each, respectively.
…

Un simple git push est rejeté comme non fast-forward. Pro Git déconseille d’inclure des commits déjà poussés sur un serveur central, car cela fournit aux autres développeurs une version altérée des mêmes modifications. Si la branche est à vous seul, utilisez la forme avec « lease » qui, d’après la documentation de git-push, protège contre la perte du travail qu’un autre aurait poussé entre-temps (ce que ne fait pas --force) :

git push --force-with-lease

…
To ../origin.git
 + 7bfd3fa...7c49854 feature/export -> feature/export (forced update)

GitMini signale ce risque avant le lancement. Dans la liste interactive, chaque commit déjà présent sur un dépôt distant affiche une icône de nuage (infobulle : Already pushed), et le pied du panneau avertit : « 3 commits in this range are already on a remote. A force push (with lease) will be required and may affect your collaborators. » Quand vous poussez une branche qui a divergé de son amont, GitMini demande de confirmer un Forced Push avec un bouton Force push, puis pousse avec lease. Après le rebase, une notification propose brièvement Undo, et l’état précédent reste dans le reflog.

Pour choisir entre fusionner et rebaser une branche, lisez merge ou rebase.

Sources

Pro Git : Rewriting History (édition anglaise), consulté le 4 octobre 2026.
Pro Git : Réécrire l’historique, consulté le 4 octobre 2026.
GitLab : guide du rebase interactif, consulté le 4 octobre 2026.
Documentation Git : git-rebase (en anglais), consulté le 4 octobre 2026.
Documentation Git : git-push (en anglais), consulté le 4 octobre 2026.
README du produit GitMini, consulté le 4 octobre 2026.