Rebase: Was es ist, wie es sich von Merge unterscheidet und Funktionsprinzip

Was ist Rebase?

Rebase (Rebasing) ist eine Git-Operation, die Commits vom aktuellen Branch zu einem neuen Basispunkt verschiebt. Anstatt einen Merge-Commit zu erstellen, nimmt Rebase jeden Commit aus dem Quellbranch und wendet ihn nacheinander auf die neue Basis an. Das Ergebnis ist eine lineare Folge von Commits ohne Verzweigungen.

Der Name Rebase kommt von „re-base“ — die Basis ändern. Während Merge zwei Branches an einem Punkt zusammenführt, verschiebt Rebase Ihren gesamten Branch effektiv an eine neue Position, sodass es aussieht, als hätten Sie die Entwicklung vom aktuellen Zustand des Zielbranches aus begonnen. Dies erzeugt die Illusion einer perfekt sequenziellen Arbeit.

Laut Atlassian, 2025 verbringen Teams, die Rebase für Feature-Branches verwenden, 30% weniger Zeit mit der Analyse der Commit-Historie im Vergleich zu Teams, die ausschließlich Merge verwenden. Die lineare Historie vereinfacht git blame, bisect und die Log-Anzeige über git log --oneline.

Grundlegender Unterschied zu Merge

Merge verbindet Branches durch die Erstellung eines Commits mit zwei Eltern. Rebase schreibt die Historie um: Neue Commits werden mit neuen Hashes erstellt, obwohl ihre Änderungen mit den Originalen identisch sind. Das bedeutet, dass Rebase die SHA-Identifikatoren der Commits ändert, was für öffentliche Branches kritisch ist.

Wie funktioniert Rebase

Der Rebase-Mechanismus besteht aus vier Schritten: Git ermittelt den gemeinsamen Vorfahren (Merge-Base) des aktuellen und des Zielbranches und wendet dann nacheinander jeden Commit des aktuellen Branches auf den Zielbranch an. Tritt in einem Schritt ein Konflikt auf, stoppt Rebase und wartet auf eine Lösung.

# Ausgangssituation: Feature-Branch liegt 3 Commits hinter Develop
git checkout feature/new-login
git rebase develop

# Git nimmt 3 Commits aus Feature und wendet sie auf Develop an
# Wenn keine Konflikte auftreten — wird Rebase automatisch abgeschlossen
# Wenn doch — stoppt Git beim konfliktreichen Commit

Nach dem Rebase enthält der Feature-Branch alle Commits von Develop plus seine eigenen Commits, die wie eine Fortsetzung von Develop aussehen. Dies ermöglicht ein Merge in Develop über Fast-Forward ohne Erstellung eines Merge-Commits.

Schritt-für-Schritt-Prozess

Betrachten wir ein detailliertes Beispiel: Ein Entwickler hat einen Feature-Branch von Develop erstellt, zwei Commits gemacht, während andere Entwickler drei Commits zu Develop hinzugefügt haben. Rebase wird die zwei Feature-Commits an eine neue Position verschieben und Kopien mit neuen SHAs erstellen.

# 1. Einen Feature-Branch erstellen
git checkout -b feature/payment-refactor develop

# 2. Commits im Feature-Branch durchführen
git commit -m "refactor: extract payment validation"
git commit -m "refactor: add payment gateway interface"

# 3. Develop aktualisieren (Arbeit der Kollegen)
git checkout develop
git pull

# 4. Feature auf den neuen Develop rebasen
git checkout feature/payment-refactor
git rebase develop

# 5. Jetzt kann Feature über Fast-Forward gemergt werden
git checkout develop
git merge feature/payment-refactor

Tritt in Schritt 4 ein Konflikt auf, stoppt Git beim problematischen Commit. Der Entwickler löst den Konflikt, führt git add und dann git rebase --continue aus. Um einen Commit zu überspringen — git rebase --skip, um das gesamte Rebase abzubrechen — git rebase --abort.

Automatisches Überspringen leerer Commits

Das --empty-Flag steuert das Verhalten von Rebase bei leeren Commits — Situationen, in denen alle Änderungen eines Commits bereits im Zielbranch vorhanden sind. Standardmäßig stoppt Rebase und fordert eine Entscheidung. Mit --empty=drop überspringt Git solche Commits automatisch ohne anzuhalten, was das massenhafte Rebasing mit einer großen Anzahl von Commits beschleunigt.

Interaktives Rebase

Interaktives Rebase (git rebase -i) ist ein leistungsstarkes Werkzeug zum Bearbeiten der Commit-Historie. Es öffnet einen Editor mit einer Liste von Commits und Schlüsselbefehlen: pick (behalten), reword (Nachricht ändern), edit (Inhalt ändern), squash (mit vorherigem zusammenführen), fixup (ohne Nachricht zusammenführen), drop (löschen).

# Interaktives Rebase der letzten 4 Commits
git rebase -i HEAD~4

# Der Editor öffnet sich mit einem Rebase-Plan:
# pick a1b2c3 feat: add login screen
# pick d4e5f6 fix: login validation
# pick g7h8i9 fix: login layout
# pick j0k1l2 docs: add login comments

# Ändern zu:
# pick a1b2c3 feat: add login screen
# squash d4e5f6 fix: login validation
# squash g7h8i9 fix: login layout
# drop j0k1l2 docs: add login comments

Ergebnis: Drei Commits (Anmeldebildschirm, Validierung, Layout) werden zu einem zusammengefasst, und der Commit mit Kommentaren wird gelöscht. Dies ermöglicht die Vorlage einer sauberen Historie zur Code-Überprüfung ohne Entwürfe und Korrekturen. Interaktives Rebase ist ein Standardwerkzeug zur Vorbereitung eines Feature-Branches vor einem Pull Request.

Rebase vs Merge: Vergleich

Rebase und Merge lösen dasselbe Problem — die Integration von Änderungen — aber auf grundlegend unterschiedliche Weise. Die Wahl zwischen ihnen hängt davon ab, welche Art von Historie Sie in git log sehen möchten und wer noch mit Ihrem Branch arbeitet.

Praktische Regel: Verwenden Sie Merge für die Integration in gemeinsame Branches (develop, main) und Rebase zum Aktualisieren persönlicher Feature-Branches. Viele Teams kombinieren beides: Rebase des Features auf Develop, dann --no-ff Merge in Develop.

Auswirkung auf git bisect

Git bisect ist ein Werkzeug zum Finden des Commits, der eine Regression eingeführt hat. Bei Verwendung von Merge durchläuft git bisect die Merge-Commits korrekt unter Berücksichtigung beider Eltern. Mit Rebase arbeitet bisect schneller, da die Historie linear ist und keine Verzweigungen erfordert. Wenn Rebase jedoch durchgeführt wurde, nachdem die Commits dem Team bekannt wurden, gehen die ursprünglichen SHAs verloren, und bisect kann den problematischen Commit möglicherweise nicht finden.

Wann Rebase verwenden

Rebase ist in drei Szenarien optimal: Vorbereitung eines Feature-Branches für einen Pull Request, Aktualisierung eines persönlichen Branches auf den aktuellen Stand von main/develop und Bereinigung der Historie vor dem Merge. In jedem Fall verbessert Rebase die Lesbarkeit der Historie ohne Risiko für die Teamarbeit.

Vor einem Pull Request wird empfohlen, ein interaktives Rebase durchzuführen, um Entwurfs-Commits (WIP, Korrekturen nach der Überprüfung) in sinnvolle logische Einheiten zusammenzufassen. Dies erleichtert die Code-Überprüfung: Der Prüfer sieht nicht 15 kleine Commits, sondern 3-5 strukturierte Änderungen mit klaren Nachrichten.

Für die Aktualisierung eines Feature-Branches ist Rebase Merge vorzuziehen, da es keine unnötigen Merge-Commits erzeugt. Wenn Sie regelmäßig git rebase develop innerhalb des Feature-Branches ausführen, hat der endgültige Merge keine Kaskade von 10 Merge-Commits — nur saubere Feature-Commits auf Develop.

Die Historie-Bereinigung durch interaktives Rebase vor dem Merge ermöglicht es, kleinere Korrekturen (Tippfehler, Formatierung) zu verbergen und Commits nach Funktionalität zu gruppieren. Git-Nachrichten sollten der Conventional Commits-Konvention folgen (fix:, feat:, refactor:, docs:), die ein automatisches Changelog generiert.

Risiken und Regeln von Rebase

Rebase ist eine gefährliche Operation, wenn sie falsch angewendet wird. Das Hauptrisiko ist das Umschreiben der veröffentlichten Historie. Wenn ein Entwickler einen Branch rebased, den andere bereits gepusht haben und verwenden, werden deren lokale Kopien nicht mehr synchron sein, und sie müssen einen Force-Pull mit dem Risiko von Datenverlust durchführen.

• Goldene Regel: Rebasen Sie niemals Commits, die bereits im gemeinsamen Repository existieren. Dies gilt für alle Branches, auf die andere Teammitglieder Zugriff haben
• Force Push: Nach dem Rebasen eines lokalen Feature-Branches ist ein Push mit dem Flag --force-with-lease erforderlich, der sicherer ist als --force, da er prüft, ob jemand den Branch auf dem Server aktualisiert hat
• Kontextverlust: Rebase zerstört Informationen darüber, wann und von welchem Branch der Feature-Branch erstellt wurde. Wenn die Aufbewahrung der Branch-Erstellungsdaten wichtig ist, verwenden Sie Merge
• Konflikte: Während des Rebase müssen Konflikte für jeden Commit einzeln gelöst werden, was bei einer großen Anzahl von Commits mühsam sein kann

Um Risiken zu minimieren, befolgen Sie diese Regel: Rebasen Sie nur persönliche Branches, die nicht veröffentlicht wurden. Wenn ein Branch bereits im gemeinsamen Repository ist, verwenden Sie Merge mit --no-ff. Wenn Sie einen veröffentlichten Branch rebasen müssen, warnen Sie das Team und koordinieren Sie den Force Push im Voraus.

Der automatische Schutz vor gefährlichem Rebase wird durch serverseitige Hooks implementiert: Ein Pre-Receive-Hook auf dem Git-Server kann prüfen, ob der Push veröffentlichte Commits überschreibt. GitHub und GitLab bieten integrierten Schutz für geschützte Branches — Force Push wird blockiert, es sei denn, der Schutz wird von einem Administrator aufgehoben.