Ein Feature-Branch ist mehrere Tage alt, im Hauptbranch hat sich viel getan, und beim Zusammenführen entsteht ein unübersichtlicher Merge-Commit – oder Konflikte tauchen an Stellen auf, die längst geklärt schienen. Genau hier hilft Git Rebase: Es kann die Projekt-Historie glätten und Änderungen so „neu aufsetzen“, als wären sie auf dem aktuellen Stand entstanden.
Damit Rebase nicht zur Stolperfalle wird, braucht es zwei Dinge: ein klares mentales Modell und ein paar feste Regeln für den Team-Alltag. Beides folgt jetzt Schritt für Schritt – ohne Mythen, aber mit genug Tiefe, um es sicher anzuwenden.
Was Git Rebase macht – in einem einfachen Bild
Ein Branch ist in Git im Kern eine Zeigerkette auf Commits. Während auf dem Hauptbranch (z. B. main) neue Commits dazukommen, arbeitet der Feature-Branch weiter auf seinem alten Stand. Mit Rebase wird die Basis (der „Abzweigpunkt“) des Feature-Branches auf einen neueren Commit verschoben.
Rebase „kopiert“ Commits und schreibt Geschichte um
Wichtig: Rebase verschiebt nicht einfach bestehende Commits. Es nimmt die Commits des Feature-Branches, spielt sie nacheinander auf den neuen Ziel-Commit und erstellt dabei neue Commits mit neuen IDs (Hashes). Das ist der Grund, warum Rebase als „History Rewrite“ gilt.
Genau daraus folgt die wichtigste Sicherheitsregel: Einen Branch, an dem andere bereits arbeiten oder der bereits geteilt wurde, sollte man nicht leichtfertig rebased veröffentlichen.
Merge vs. Rebase: Was ist eigentlich der Unterschied?
Ein Merge führt zwei Entwicklungsstränge zusammen und erzeugt oft einen Merge-Commit. Rebase dagegen versucht, die Commits linear anzuordnen, sodass die Historie wirkt, als sei alles in einer geraden Linie entstanden. Beides ist korrekt – aber mit unterschiedlichen Zielen.
| Situation | Merge | Rebase |
|---|---|---|
| Historie soll nachvollziehbare „Zusammenführungen“ zeigen | gut geeignet | eher unpassend |
| Historie soll möglichst linear und ruhig bleiben | kann unruhig werden | gut geeignet |
| Branch wurde schon von anderen gepullt | meist sicher | riskant (neue Commit-IDs) |
| Konflikte früh klären, bevor gemerged wird | möglich | sehr gut möglich |
Wann Rebase sinnvoll ist – und wann besser nicht
Rebase ist kein „Standard-Schritt“, sondern ein Werkzeug für konkrete Ziele: saubere Historie, weniger Merge-Rauschen, Konflikte früher klären. In Teams ist nicht die Technik entscheidend, sondern die Absprachen.
Typische gute Anwendungsfälle
- Ein lokaler Feature-Branch soll auf den aktuellen Stand von main gebracht werden, bevor ein Pull Request erstellt wird.
- Ein Pull Request soll eine lineare, gut lesbare Historie ohne „Merge main into feature“ haben.
- Commits sollen vor dem Teilen aufgeräumt werden (z. B. Tippfehler-Commits zusammenfassen).
Situationen, in denen Rebase oft Probleme macht
- Der Branch ist bereits gemeinsam genutzt (mehrere Personen pushen darauf).
- Es gibt automatisierte Prozesse, die auf Commit-IDs basieren (selten, aber möglich).
- Das Team nutzt bewusst Merge-Commits als „Release-/Feature-Grenzen“ in der Historie.
Rebase im Alltag: Branch aktualisieren, ohne Chaos
Der häufigste Workflow ist: Feature-Branch aktualisieren, Konflikte lösen, Tests laufen lassen, dann Pull Request. Dabei ist die Kernfrage: Soll der Branch einen Merge-Commit bekommen oder nicht? Wenn nicht, ist Rebase der übliche Weg.
Praktische Schritte für ein sauberes Update
- Auf den Feature-Branch wechseln: git checkout feature-xyz
- Aktuellen Stand holen: git fetch origin
- Rebase auf main: git rebase origin/main
- Falls Konflikte auftreten: Konflikte lösen, dann fortsetzen: git rebase –continue
- Am Ende Tests/Build lokal ausführen und erst dann pushen
Wenn der Branch bereits auf dem Remote liegt, braucht es nach einem Rebase meist ein Force-Push – und genau hier passieren die meisten Unfälle.
Force-Push richtig: warum „–force-with-lease“ wichtig ist
Nach einem Rebase passen lokale und entfernte Historie nicht mehr zusammen, weil neue Commit-IDs entstanden sind. Ein normaler Push wird abgelehnt. Der naive Ausweg ist git push –force – der kann jedoch fremde Commits überschreiben.
Besser ist: git push –force-with-lease. Damit wird nur dann überschrieben, wenn der Remote-Branch noch den Stand hat, den lokal erwartet wird. Wenn in der Zwischenzeit jemand anderes gepusht hat, bricht Git ab – und verhindert Datenverlust.
Konflikte beim Rebase lösen – mit klarer Routine
Konflikte wirken beim Rebase manchmal „häufiger“, weil jeder Commit einzeln neu angewendet wird. Das ist aber auch ein Vorteil: Konflikte werden genau dort gelöst, wo sie entstanden sind – Commit für Commit.
Ein stabiles Vorgehen bei Konflikten
- Konfliktdateien öffnen und die Konfliktmarker entfernen (Git zeigt die Stellen im Code).
- Entscheiden, welche Variante fachlich richtig ist (nicht nur „was kompiliert“).
- Dateien als gelöst markieren: git add <datei>
- Rebase fortsetzen: git rebase –continue
- Wenn es völlig falsch läuft: git rebase –abort (bringt den Branch zurück wie vor dem Start)
Hilfreich ist eine feste Mini-Regel: Nach jedem gelösten Konflikt kurz testen (z. B. Unit-Tests oder wenigstens ein Build). So wird verhindert, dass sich Fehler über mehrere Rebase-Schritte mitschleppen.
Konflikte vermeiden: kleine Commits und klare Themen
Je größer und gemischter ein Commit ist, desto schwerer wird eine Konfliktauflösung. Kleine, thematisch saubere Commits reduzieren Konflikte und machen Entscheidungen leichter. Das passt auch zu einem guten Review-Prozess.
Wer die allgemeine Historie im Team verbessern will, profitiert zusätzlich von einem klaren Branching-Workflow, siehe Git Branching verstehen – Workflow für Teams ohne Chaos.
Interaktives Rebase: Commits vor dem Teilen aufräumen
Interaktives Rebase ist ideal, um lokale Arbeit in eine Form zu bringen, die Reviews erleichtert. Typische Ziele: Commit-Nachrichten verbessern, kleine „Fix“-Commits zusammenfassen oder die Reihenfolge sinnvoll sortieren.
Was dabei wirklich passiert
Beim interaktiven Rebase wird eine Liste der letzten Commits geöffnet. Dort kann festgelegt werden, was mit jedem Commit passieren soll (z. B. behalten, zusammenfassen, Nachricht ändern). Auch hier gilt: Es entstehen neue Commits mit neuen IDs.
Typische, sinnvolle Aufräum-Aktionen
- Mehrere Mini-Fixes zu einem fachlichen Commit zusammenführen (z. B. „validiere Eingaben“ statt fünf Kleinst-Commits).
- Commit-Message präzisieren, damit der Zweck sofort klar ist.
- Reihenfolge anpassen, damit ein Commit nicht auf Änderungen „wartet“, die erst später kommen.
Wer beim Thema saubere Änderungs-Sets tiefer einsteigen will, findet ergänzend Praxis-Ideen in Refactoring im bestehenden Code – Schritt für Schritt zu besserer Wartbarkeit.
Entscheidungshilfe für Teams: Rebase-Regeln, die funktionieren
Die beste Rebase-Strategie ist die, die im Team klar kommuniziert ist. Ein häufiger Konflikt entsteht, wenn einzelne Personen rebased pushen, während andere Merge-Commits erwarten. Deshalb helfen einfache Regeln, die zu den Tools passen (GitHub/GitLab/Bitbucket).
- Wenn ein Branch privat ist (nur lokal oder nur eine Person): Rebase ist meist okay.
- Vor einem Pull Request: Branch auf origin/main rebasen, damit der PR sauber bleibt.
- Nach dem Rebase nur mit force-with-lease pushen, falls der Branch remote liegt.
- Wenn ein Branch geteilt ist (mehrere Personen arbeiten daran): eher mergen.
- Rebase nur nach Absprache und wenn alle Beteiligten wissen, wie sie ihre lokalen Branches anpassen.
- Wenn das Team eine lineare Historie im Zielbranch will: „Rebase and merge“ (Server-seitig) nutzen.
- Dann bleibt main linear, ohne dass alle lokal ständig force-pushen müssen.
Häufige Stolpersteine und wie sie sich vermeiden lassen
„Warum sind nach dem Rebase plötzlich doppelte Commits im PR?“
Das passiert oft, wenn auf den falschen Zielbranch rebased wurde oder lokale Branches/Remotes nicht aktuell waren. Ein sauberes git fetch vor dem Rebase und das Rebasen auf origin/main statt auf einen veralteten lokalen main reduziert das Risiko.
„Kann Rebase Code verlieren?“
Rebase an sich verliert keinen Code, aber ein unvorsichtiger Force-Push kann fremde Arbeit überschreiben. Deshalb ist force-with-lease die sicherere Standardwahl. Im Notfall hilft oft auch das Auffinden alter Commits über die Git-Historie (z. B. reflog), aber darauf sollte man sich nicht verlassen müssen.
„Ist Rebase besser als Merge?“
Nein – es ist ein anderes Werkzeug. Merge ist oft das bessere Team-Werkzeug, Rebase ist oft das bessere Aufräum-Werkzeug. In beiden Fällen sollte das Ziel klar sein: gute Nachvollziehbarkeit, wenig Risiko, leichte Reviews.
Wer in Reviews häufig über „Warum ist dieser Commit hier drin?“ stolpert, sollte außerdem die Fehlerausgabe und Statuscodes der eigenen Schnittstellen klar gestalten, damit Änderungen leichter zu testen sind. Passend dazu: API-Design mit Statuscodes – klare Fehler für stabile Webapps.
