Übersicht

git rebase -i <upstream>
git rebase -i --root

Beschreibung

Interaktives Rebase öffnet einen Editor mit der Liste der zu rebasenden Commits, jeder vorangestellt mit einer Aktion: pick, reword, edit, squash, fixup, drop, exec oder break. Durch Bearbeiten dieser Liste können Sie Commits umordnen, kombinieren, aufteilen oder entfernen, bevor sie upstream gehen. Es ist das Arbeitspferd zum "Aufräumen der Historie vor dem Pushen".

Kombiniert mit --autosquash werden via git commit --fixup erzeugte Fixup-Commits automatisch neben ihren Zielen angeordnet und zum Squashen markiert. Das --rebase-merges-Flag bewahrt Merge-Commits während des interaktiven Rebase.

Im täglichen Einsatz integriert sich git rebase -i eng mit Shell-Aliasen, Editor-Plugins und Continuous Integration. Power-User fügen oft Aliase hinzu, die Flags kombinieren, die sie immer übergeben, oder wickeln den Befehl in Skripte, die Teamkonventionen durchsetzen. Die Ausgabeformatierung kann über Git-Config angepasst werden — Pretty-Formate, Farbschemata und Pager-Verhalten sind alle einstellbar. Wenn etwas schiefgeht, ist der erste Diagnoseschritt üblicherweise, den Befehl erneut mit GIT_TRACE=1 in der Umgebung auszuführen, was die zugrunde liegenden Plumbing-Aufrufe offenlegt. Für ungewöhnliche Situationen öffnet die --help-Ausgabe (git rebase -i --help) die vollständige Manpage mit Details zu jeder Option, einschließlich solcher, die in alltäglichen Workflows selten verwendet werden, aber für Debugging oder Skripting im großen Maßstab essentiell sind.

Zu verstehen, wie git rebase -i mit dem Rest von Gits Datenmodell interagiert — der Objektdatenbank, dem Index, Refs und dem Working Tree — zahlt sich aus. Jeder Befehl operiert auf einer Teilmenge dieser Stücke, und zu wissen, welche er berührt, hilft Ergebnisse vorherzusagen und sich von Fehlern zu erholen. Das Lesen der offiziellen Git-Dokumentation neben praktischer Übung in einem Wegwerf-Repository ist der schnellste Weg, die Nuancen zu verinnerlichen. Die meisten Produktionsprobleme mit Git rühren von einer von drei Ursachen: überraschendem Standardverhalten, partiellen Netzwerkoperationen oder dem Umschreiben bereits geteilter Historie. Ein funktionierendes mentales Modell der Nebenwirkungen von git rebase -i hilft, alle drei zu vermeiden.

Häufige Optionen

Option	Beschreibung
-i	Interaktiver Editor für den Rebase-Plan.
--autosquash	Ordnet Fixup/Squash-Commits automatisch an.
--root	Rebaset vom allerersten Commit.
-x <cmd>	Führt einen Befehl zwischen Commits aus (z. B. Tests).
-r, --rebase-merges	Bewahrt Merge-Commits.
--continue	Setzt nach Konfliktauflösung fort.
--abort	Bricht vollständig ab.

Beispiele

git rebase -i HEAD~5
    # Die letzten 5 Commits bearbeiten

    git commit --fixup abc123
    git rebase -i --autosquash abc123^
    # Einen Fixup hinzufügen, dann beim Rebase auto-squashen

    git rebase -i -x "npm test" main
    # Tests nach jedem Commit während des Rebase ausführen

    git rebase -i --root
    # Historie ab dem ersten Commit umschreiben

Häufige Fehler

Eine leere Rebase-Todo-Liste zu speichern bricht die Operation ab — lassen Sie mindestens eine pick-Zeile stehen. Zu viele Commits als edit zu markieren erzeugt eine mühsame Sequenz von Stopps; bevorzugen Sie squash oder fixup, wenn Sie nur kombinieren wollen. Rebasen Sie niemals interaktiv Commits, die bereits gepusht und geteilt sind.

Verwandte Befehle

git rebase, git commit --fixup, git cherry-pick, git reflog