Von Gast (nicht überprüft) , 29 April 2026

Übersicht

git rebase [-i] [--onto <newbase>] [<upstream> [<branch>]]

Beschreibung

Der git rebase-Befehl bewegt eine Folge von Commits auf eine neue Basis. Er schreibt Historie um, indem er jeden Commit auf der neuen Basis erneut abspielt und so eine lineare Kette statt eines Merge-Commits erzeugt. Rebasen ist unschätzbar, um Feature-Branches aktuell zu halten, lokale Historie vor dem Pushen aufzuräumen und Fixup-Commits zu squashen.

Da Rebasen neue Commits mit anderen SHAs erzeugt, rebasen Sie niemals Commits, die veröffentlicht und von anderen gepullt wurden — diese würden mit divergierenden Historien enden. Der interaktive Modus (-i) erlaubt es Ihnen, Commits umzuordnen, zu bearbeiten, zu squashen, zu löschen oder zu fixen.

Im täglichen Einsatz integriert sich git rebase 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 --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 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 hilft, alle drei zu vermeiden.

Häufige Optionen

OptionBeschreibung
-i, --interactiveÖffnet einen Editor zum Bearbeiten der Commit-Liste.
--onto <newbase>Rebaset auf einen beliebigen Commit, nicht den Upstream.
--continueSetzt nach Konfliktauflösung fort.
--abortBricht das Rebase ab und kehrt in den Ausgangszustand zurück.
--skipÜberspringt den aktuellen Patch und fährt fort.
--autosquashOrdnet fixup/squash-Commits automatisch an.
--autostashStasht lokale Änderungen vor dem Rebase und popt danach.
-r, --rebase-mergesBewahrt Merge-Commits während des Rebase.

Beispiele

git rebase main
    # Commits des aktuellen Branches auf main neu abspielen

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

    git rebase --onto main feature-base feature-tip
    # Nur Commits zwischen feature-base und feature-tip auf main verschieben

    git rebase --continue
    # Nach Konfliktauflösung fortsetzen

Häufige Fehler

Das Rebasen von öffentlichen, geteilten Branches bricht die Historie jedes Mitwirkenden. Reservieren Sie Rebase für lokale Aufräumarbeiten. Während der Konfliktauflösung führen Anfänger oft git commit statt git rebase --continue aus, was das Rebase in einem kaputten Zustand hinterlässt. Wenn Sie sich mitten im Rebase verirren, bringt git rebase --abort Sie immer in Sicherheit zurück.

Verwandte Befehle

git merge, git cherry-pick, git reflog, git pull --rebase