Git Rebase verstehen: Eine saubere Historie ohne Merge-Chaos

Wenn du mit Branches arbeitest, kennst du das Problem: Nach ein paar Wochen sieht deine Git-Historie aus wie ein Gleisplan – überall Merge-Commits, kreuz und quer verlaufende Linien, und niemand weiß mehr, in welcher Reihenfolge Features eigentlich entstanden sind. Genau hier kommt git rebase ins Spiel. Es ist die Alternative zum Merge, die deine Historie linear und lesbar hält. In diesem Beitrag lernst du, was Rebase wirklich tut, wann du es einsetzen solltest – und wann besser nicht.

Was macht Rebase eigentlich?

Stell dir vor, du hast einen Feature-Branch von main abgezweigt. Während du entwickelst, bekommt main neue Commits von deinen Kollegen. Mit git merge main würdest du diese Änderungen in deinen Branch holen und dabei einen zusätzlichen Merge-Commit erzeugen. Rebase geht anders vor: Es nimmt deine Commits, legt sie beiseite, setzt deinen Branch auf den neuesten Stand von main und spielt deine Commits anschließend einzeln wieder oben drauf.

# Auf dem Feature-Branch:
git checkout feature/login
git rebase main

# Danach sieht es so aus, als hättest du deinen Branch
# erst heute von main abgezweigt - eine gerade Linie.

Das Ergebnis: keine Merge-Commits, keine Verzweigungen – die Historie liest sich wie ein Buch, Commit für Commit. Wichtig zu verstehen: Deine Commits werden dabei neu erzeugt. Sie haben denselben Inhalt, aber neue Commit-Hashes, weil sich ihre Position in der Historie geändert hat.

Rebase vs. Merge: Wann nimmst du was?

Beide Kommandos bringen Änderungen zusammen, aber mit unterschiedlicher Philosophie. Als Faustregel hat sich in vielen Teams dieser Workflow bewährt:

• Rebase, um deinen Feature-Branch aktuell zu halten: Du holst dir regelmäßig den neuesten Stand von main, ohne die Historie zu verschmutzen.
• Merge (oft als Squash- oder Fast-Forward-Merge), um den fertigen Feature-Branch zurück in main zu bringen – meist über einen Pull Request.
• Niemals rebasen, was schon geteilt wurde: Branches, auf denen andere aufbauen, fasst du mit Rebase nicht an.

Der letzte Punkt ist die goldene Regel. Weil Rebase Commits neu schreibt, bekommen Kollegen, die deinen alten Stand ausgecheckt haben, massive Konflikte. Auf deinem eigenen, noch nicht gepushten oder nur von dir genutzten Branch ist Rebase dagegen völlig unbedenklich.

Konflikte beim Rebase lösen

Da Rebase deine Commits einzeln neu anwendet, können Konflikte auftreten – und zwar pro Commit statt einmal gesammelt wie beim Merge. Das klingt lästig, macht Konflikte aber oft kleiner und übersichtlicher. Der Ablauf:

git rebase main
# KONFLIKT in src/auth.js

# 1. Konflikt in der Datei beheben, dann:
git add src/auth.js

# 2. Rebase fortsetzen:
git rebase --continue

# Oder alles abbrechen und zum Ausgangszustand zurück:
git rebase --abort

Merke dir vor allem git rebase --abort: Es bringt dich jederzeit zurück zum Zustand vor dem Rebase. Du kannst also nichts kaputt machen, solange du im Zweifel abbrichst und neu ansetzt.

Interaktives Rebase: Commits aufräumen

Die eigentliche Superkraft steckt in git rebase -i (interactive). Damit bearbeitest du deine eigene Commit-Historie, bevor du sie mit anderen teilst: Commits zusammenfassen, umbenennen, neu sortieren oder löschen.

# Die letzten 4 Commits bearbeiten:
git rebase -i HEAD~4

Git öffnet deinen Editor mit einer Liste der Commits und einem Befehl pro Zeile:

pick a1b2c3d Login-Formular hinzugefuegt
squash e4f5g6h Tippfehler behoben
squash i7j8k9l Noch ein Fix
reword m0n1o2p Validierung eingebaut

# pick   = Commit unveraendert uebernehmen
# squash = mit dem vorherigen Commit verschmelzen
# reword = Commit behalten, aber Nachricht aendern
# drop   = Commit komplett entfernen

In diesem Beispiel werden die beiden Fix-Commits in den Login-Commit gequetscht und die Nachricht des Validierungs-Commits überarbeitet. Aus vier unordentlichen Commits werden zwei saubere. Genau so entstehen die aufgeräumten Pull Requests, die Reviewer lieben: Jeder Commit erzählt einen abgeschlossenen, nachvollziehbaren Schritt.

Wenn etwas schiefgeht: das Reflog

Viele haben Angst, sich mit Rebase Commits zu zerschießen. Die Entwarnung: Git wirft so gut wie nichts sofort weg. Das Reflog protokolliert jede Bewegung deines HEAD – auch die Zustände vor einem Rebase.

# Verlauf aller HEAD-Positionen anzeigen:
git reflog
# a1b2c3d HEAD@{0}: rebase (finish): ...
# 9z8y7x6 HEAD@{1}: rebase (start): ...
# 5f4e3d2 HEAD@{2}: commit: Validierung eingebaut

# Zurueck zum Zustand vor dem Rebase:
git reset --hard HEAD@{2}

Mit git reset --hard HEAD@{n} springst du zu jedem früheren Zustand zurück. Ein misslungener Rebase ist damit kein Drama, sondern nur ein Umweg.

Praktische Helfer für den Alltag

Zwei Optionen machen Rebase im Teamalltag deutlich angenehmer. Erstens: git pull --rebase holt Änderungen vom Remote und rebased deine lokalen Commits obendrauf, statt einen unnötigen Merge-Commit zu erzeugen. Das kannst du dauerhaft aktivieren. Zweitens: --autosquash in Kombination mit Fixup-Commits.

# pull standardmaessig als Rebase ausfuehren:
git config --global pull.rebase true

# Einen Fix fuer einen bestimmten Commit markieren:
git commit --fixup a1b2c3d

# Beim interaktiven Rebase wird er automatisch
# an die richtige Stelle sortiert und gesquasht:
git rebase -i --autosquash main

So sammelst du während der Entwicklung kleine Korrekturen als fixup-Commits und räumst sie am Ende mit einem einzigen Befehl auf.

Fazit

Rebase ist kein Hexenwerk, sondern ein Werkzeug mit einer klaren Aufgabe: eine lineare, lesbare Historie. Nutze es, um deinen Feature-Branch aktuell zu halten und deine Commits vor dem Pull Request aufzuräumen – und halte dich an die goldene Regel, niemals geteilte Branches umzuschreiben. Mit git rebase --abort und dem Reflog hast du außerdem immer ein Sicherheitsnetz. Probiere das interaktive Rebase am besten in einem Übungs-Repository aus: Nach zwei, drei Durchläufen möchtest du die aufgeräumten Historien nicht mehr missen.