Rebase: was ist das, wie funktioniert rebase und Arbeit mit Git

Was ist Rebase in Git

Rebase ist ein Git-Befehl, der den aktuellen Branch auf einen angegebenen Branch umsetzt: Er nimmt alle Commits des aktuellen Branches, speichert sie temporär, verschiebt den Branch-Zeiger auf den Ziel-Commit und wendet die gespeicherten Commits nacheinander darauf an. Das Ergebnis — der Verlauf sieht so aus, als hätte der Entwickler direkt vom letzten Commit des Zielbranches aus gearbeitet.

Die grundlegende Syntax: git rebase main — während man sich in einem Feature-Branch befindet, verschiebt dieser Befehl alle Feature-Commits an die Spitze von main. Git verwendet für jeden einzelnen Commit eine Three-Way-Merge-Strategie. Wenn Commit A bereits im Zielbranch vorhanden ist (ermittelt durch Hash), überspringt Git ihn automatisch und vermeidet so doppelte Änderungen.

Rebase unterstützt auch den onto-Modus zum Verschieben einer Teilmenge von Commits: git rebase --onto target start end — diese Form erlaubt es, einen Bereich von Commits aus einem Branch zu extrahieren und auf einen anderen anzuwenden. Zum Beispiel verschiebt git rebase --onto main feature~3 feature die letzten drei Commits des Feature-Branches auf main.

# Switch to feature branch
git checkout feature

# Rebase feature onto main
git rebase main

# After successful rebase — history is linear
git log --oneline --graph

# Move last 3 commits to main
git rebase --onto main HEAD~3 HEAD

Rebase vs Merge: Hauptunterschiede

Rebase und Merge lösen dieselbe Aufgabe — das Zusammenführen von Änderungen aus verschiedenen Branches — aber auf grundlegend unterschiedliche Weise. Merge bewahrt die vollständige Merge-Historie, indem es einen Merge-Commit mit zwei Eltern erstellt. Rebase überschreibt die Historie und macht sie linear. Die Wahl zwischen ihnen hängt vom Workflow des Teams und den Regeln der Repository-Verwaltung ab.

Der Hauptunterschied ist wie der Merge-Vorgang aufgezeichnet wird. Merge bewahrt: „an diesem Punkt haben wir feature in main gemergt“ — das ist informativ für die Projekt-Historie, aber verstopft das Protokoll bei häufigen Merges. Rebase zeigt: „Feature-Commits wurden nacheinander vom letzten main-Stand aus erstellt“ — das ist sauber, verbirgt aber die Tatsache, dass parallel entwickelt wurde.

Der zweite Unterschied ist die Konfliktbehandlung. Bei Merge werden Konflikte einmal gelöst und die Lösung im Merge-Commit festgehalten. Bei Rebase können für jeden verschobenen Commit Konflikte auftreten, die jeweils eine separate Lösung erfordern. Das ist aufwändiger, ermöglicht aber eine genauere Kontrolle darüber, welche Änderungen in die endgültige Version gelangen.

Interaktiver Rebase: Befehle und Flags

Interaktiver Rebase (git rebase -i) ist ein Modus, in dem Git einen Editor mit einer Liste von Commits und verfügbaren Aktionen für jeden öffnet. Der Entwickler kann die Historie vor dem Pushen in ein entferntes Repository umschreiben. Dies ist das primäre Werkzeug, um saubere Commits in einem Feature-Branch zu erhalten.

Verfügbare Befehle im interaktiven Modus: pick (Commit unverändert lassen), reword (Commit-Nachricht ändern), edit (für Änderungen anhalten), squash (mit vorherigem Commit zusammenführen, beide Nachrichten behalten), fixup (zusammenführen, Nachricht verwerfen), drop (Commit löschen). Jeder Befehl wird im geöffneten Editor vor dem Commit-Hash platziert.

Squash und Fixup sind die am häufigsten verwendeten Befehle zum Kombinieren von Commits. Wenn ein Entwickler während der Arbeit 5 kleine Korrektur-Commits gemacht hat, führt squash sie zu einem logischen Commit mit einer aussagekräftigen Nachricht zusammen. Fixup ist nützlich, um Tippfehler zu korrigieren: Änderungen gelangen in den vorherigen Commit, ohne ihre eigene Nachricht zu behalten.

# Open editor for last 4 commits
git rebase -i HEAD~4

# Editor will show:
pick a1b2c3d Add authentication
pick e4f5g6h Fix typo in login
squash i6j7k8l Additional login fixes
pick m9n0o1p Add auth tests

# After saving — Git performs rebase
# and opens editor for squashed commit message

# Auto-squash without opening editor
git rebase -i HEAD~4 --autosquash

Das Flag --autosquash ordnet automatisch fixup/squash für Commits an, deren Nachrichten mit fixup! oder squash! beginnen. Das beschleunigt die Arbeit, wenn der Entwickler Commits vorab für die spätere Zusammenführung markiert. Das Flag --committer-date-is-author-date bewahrt das ursprüngliche Commit-Datum beim Rebasen — nützlich, um die zeitliche Chronologie im Verlauf zu erhalten.

Konfliktlösung bei Rebase

Konflikte beim Rebase treten auf, wenn Git einen verschobenen Commit aufgrund von Widersprüchen mit Änderungen im Zielbranch nicht automatisch anwenden kann. Anders als bei Merge, wo der Konflikt einmal gelöst wird, kann bei Rebase jeder Commit einen Konflikt verursachen, der für jeden Commit nacheinander vom ältesten zum neuesten gelöst werden muss.

Wenn ein Konflikt auftritt, pausiert Git den Rebase und meldet, welcher Commit das Problem verursacht hat. Der Entwickler öffnet die konfliktbehaftete Datei (Git markiert Konfliktbereiche mit <<<<<<<, =======, >>>>>>>-Markierungen), bearbeitet sie, fügt sie zum Index hinzu (git add) und setzt den Rebase mit git rebase --continue fort. Wenn keine Lösung gefunden wird — git rebase --abort bricht den Rebase vollständig ab.

Tipp: bei mehreren Konflikten ist es effizienter, git mergetool zu verwenden, das einen visuellen Editor zur Konfliktlösung öffnet. Man kann den problematischen Commit auch überspringen (git rebase --skip), aber das entfernt seine Änderungen aus der endgültigen Historie, was selten die richtige Entscheidung ist.

# Start rebase with conflict
git rebase main
# Auto-merging file.txt
# CONFLICT (content): Merge conflict in file.txt

# Check status
git status
# both modified: file.txt

# Edit conflicted sections → git add → continue
git add file.txt
git rebase --continue

# If uncertain — abort
git rebase --abort

Wann man Rebase nicht machen sollte

Die goldene Regel von Rebase: Rebase niemals Commits, die bereits in ein entferntes Repository gepusht und für andere Entwickler verfügbar sind. Da Rebase die Commit-Hashes überschreibt, werden Kollegen bei der Synchronisierung auf Konflikte stoßen — ihre lokale Historie wird von der umgeschriebenen entfernten Historie abweichen.

Eine Situation, in der Rebase kategorisch verboten ist: wenn jemand bereits einen Branch basierend auf Ihren Commits erstellt hat (z. B. hat ein Kollege einen Branch von Ihrem Feature-Branch abgezweigt), würde das Umschreiben der Historie seine Arbeit zerstören. In solchen Fällen sollte Merge verwendet werden. Es wird auch nicht empfohlen, kurz vor einer Deadline zu rebasen — ein Fehler bei der Konfliktlösung kann länger dauern als erwartet und die Veröffentlichung blockieren.

Ausnahme: wenn der Branch nur von einem einzigen Entwickler verwendet wird (persönlicher Feature-Branch, nicht veröffentlicht oder im Entwurfsmodus veröffentlicht), ist Rebase vor dem Push eine Standardpraxis. Nach der Veröffentlichung und dem Beginn der Zusammenarbeit — nur Merge. GitHub und GitLab bieten standardmäßig Squash Merge als Kompromiss an: es fasst Commits zu einem zusammen, überschreibt aber nicht die Historie des Zielbranches.

• Öffentliche Branches (main, develop, release) — Rebase ist vollständig verboten.
• Fremde Commits — wenn der Branch Commits eines anderen Entwicklers enthält, ist Rebase nicht zulässig.
• Vor der Veröffentlichung — Konfliktrisiken sind höher: Merge ist einen Tag vor der Deadline sicherer.
• Branches mit Tags — das Verschieben eines Commits mit Tag verstößt gegen die Konventionen des semantischen Versionierens.
• CI/CD an Hashes gebunden — einige Bereitstellungssysteme identifizieren Builds anhand des Commit-Hashes; Rebase würde die Nachverfolgung brechen.

Praktischer Workflow mit Rebase

Moderne Teams verwenden am häufigsten einen Rebase-orientierten Workflow in Kombination mit GitHub Flow. Der Prozess sieht so aus: Der Entwickler erstellt einen Feature-Branch von main, arbeitet darin, synchronisiert regelmäßig über git rebase main und führt vor dem Erstellen eines Pull-Requests einen interaktiven Rebase durch, um die Historie zu bereinigen.

Nach dem Erstellen eines PR (wenn neue Änderungen aus main eingezogen werden müssen) wird git pull --rebase main anstelle eines normalen git pull verwendet. Dadurch werden Änderungen ohne Erstellen eines unnötigen Merge-Commits eingezogen. Git pull mit dem Flag --rebase ist äquivalent zu git fetch + git rebase — Git lädt zunächst neue Commits herunter und setzt dann lokale Änderungen darauf um.

Git erlaubt es, Rebase als Standardverhalten für Pull zu konfigurieren: git config --global pull.rebase true. Nach dieser Einstellung führt git pull immer Rebase statt Merge aus. Wenn ein normaler Pull benötigt wird — verwendet man git pull --no-rebase. Viele Teams aktivieren auch Autostash: git config --global rebase.autoStash true — dies versteckt nicht-committete Änderungen automatisch vor dem Rebase und stellt sie danach wieder her.