Merge vs. Rebase: Eine Entscheidungshilfe

1. Was Merge und Rebase beide lösen wollen

Sobald zwei Entwickler parallel an einem Repository arbeiten, entstehen zwangslaeufig divergierende Commit-Historien. Ein Feature-Branch und der main-Branch laufen auseinander, weil auf beiden Seiten neue Commits entstehen. git merge und git rebase lösen exakt dasselbe Grundproblem: divergierende Branches wieder zusammenfuehren, sodass ein Branch die Änderungen des anderen enthaelt. Der Unterschied liegt nicht im Ziel, sondern im Weg dorthin und in dem, was danach in der Historie sichtbar bleibt.

Ohne eines der beiden Werkzeuge liesse sich ein Feature-Branch nie sauber in main integrieren, ohne Änderungen manuell per Patch zu uebertragen. Git verfolgt für jeden Commit seine Eltern-Commits, und genau diese Eltern-Beziehung ist der Kern des Unterschieds: merge fuegt einen neuen Commit mit zwei Elternteilen hinzu, rebase erzeugt für jeden urspruenglichen Commit einen neuen Commit mit genau einem Elternteil auf der Zielbasis. Wer diesen strukturellen Unterschied verinnerlicht, versteht sofort, warum die Wahl zwischen beiden Befehlen weitreichende Folgen für Team-Workflows hat.

2. Wie git merge intern funktioniert

git merge fuehrt in den meisten Faellen einen Drei-Wege-Merge (three-way merge) durch. Git betrachtet drei Punkte: den gemeinsamen Vorfahren beider Branches (den Merge-Base), den aktuellen Stand des Ziel-Branches und den aktuellen Stand des zu integrierenden Branches. Aus dem Vergleich dieser drei Zustaende berechnet Git, welche Änderungen auf welcher Seite vorgenommen wurden, und wendet beide Aenderungssaetze automatisch an, sofern sie sich nicht ueberschneiden.

Das Ergebnis eines nicht trivialen Merges ist ein neuer Merge-Commit mit zwei Eltern-Commits: dem letzten Commit des Ziel-Branches und dem letzten Commit des integrierten Branches. Dieser Merge-Commit enthaelt selbst keine inhaltlichen Änderungen, sondern dokumentiert lediglich, dass und wann zwei Historien zusammengefuehrt wurden. Alle urspruenglichen Commits beider Branches bleiben unveraendert erhalten, inklusive ihrer originalen SHA-Hashes, Zeitstempel und Autoren. Genau diese Unveraenderlichkeit macht Merge zur sicheren Wahl für bereits veroeffentlichte Historie.

# Standard merge workflow: integrate a feature branch into main
git checkout main
git pull origin main
git merge feature/checkout-redesign

# If Git cannot auto-resolve, conflict markers appear in files
# <<<<<<< HEAD ... ======= ... >>>>>>> feature/checkout-redesign
git status
git add resolved-file.php
git commit

3. Wie git rebase intern funktioniert

git rebase verfolgt einen fundamental anderen Ansatz: Statt die beiden Historien mit einem verbindenden Commit zusammenzufuehren, spielt Git die Commits eines Branches einzeln, in ihrer urspruenglichen Reihenfolge, auf einer neuen Basis erneut ab. Fuer jeden Commit des zu rebasenden Branches berechnet Git dessen Diff (die inhaltliche Aenderung), wendet diesen Diff auf die neue Basis an und erstellt daraus einen komplett neuen Commit.

Dieser neue Commit hat zwangslaeufig einen anderen SHA-Hash als der urspruengliche, selbst wenn der Inhalt identisch ist, weil der Hash unter anderem vom Eltern-Commit und vom Zeitstempel abhaengt. Die alten Commits werden dabei nicht geloescht, sondern bleiben zunaechst im Reflog erreichbar, aber der Branch-Zeiger verweist danach auf die neue Commit-Kette. Nach einem erfolgreichen Rebase sieht die Historie aus, als waeren alle Feature-Commits von Anfang an linear auf dem aktuellen Stand des Ziel-Branches entstanden. Dieses Umschreiben der Historie ist gleichzeitig die größte Staerke und die größte Gefahr von Rebase.

# Rebase a local feature branch onto the latest main
git checkout feature/checkout-redesign
git fetch origin
git rebase origin/main

# Git replays each commit one by one, updating the branch pointer at the end
git log --oneline -5

4. Die goldene Regel: niemals geteilte Historie rebasen

Die wichtigste Regel im Umgang mit Rebase lautet: Rebase niemals Commits, die bereits auf einen geteilten Branch gepusht wurden und von denen andere Entwickler bereits einen Stand ausgecheckt haben koennten. Der Grund liegt in der Natur des Umschreibens: Ein Rebase erzeugt neue Commits mit neuen SHA-Hashes, die aus Git-Sicht in keiner Beziehung zu den alten Commits stehen. Wer einen bereits gepushten Branch rebast und danach mit git push --force ueberschreibt, laesst die alten Commits auf dem Remote verschwinden und ersetzt sie durch scheinbar unabhaengige neue.

Fuer Teammitglieder, die den alten Stand bereits lokal ausgecheckt haben, entsteht dadurch eine divergierende Historie: Ihr lokaler Branch basiert noch auf den alten Commits, der Remote-Branch aber auf den neuen. Ein einfacher git pull fuehrt dann entweder zu einem chaotischen Merge mit doppelten Commits oder zu einer Fehlermeldung. Die einzigen sauberen Auswege sind ein erneutes git rebase auf Teammitglieder-Seite oder das komplette Neuklonen des Branches, beides mit Risiko für verlorene lokale Änderungen. Diese goldene Regel ist branch-, nicht befehlsspezifisch: Ein lokaler, noch nicht gepushter Feature-Branch darf beliebig rebast werden, ein bereits von Kollegen genutzter Branch nicht.

5. Wann Merge die richtige Wahl ist

Merge ist die richtige Wahl, sobald echte, gemeinsam genutzte Historie erhalten bleiben soll. Beim Zusammenfuehren von langlebigen, geteilten Branches wie Release-Branches in main dokumentiert der Merge-Commit exakt, wann und wie ein Feature integriert wurde. Diese Nachvollziehbarkeit ist bei Audits, Hotfix-Analysen und der Frage „welcher Release enthaelt diesen Commit“ von direktem praktischem Wert, weil git log --merges und git log --first-parent die Integrationspunkte klar sichtbar machen.

Auch bei jedem Branch, an dem bereits mehrere Personen gearbeitet haben oder der bereits gepusht und von anderen ausgecheckt wurde, ist Merge die sicherere Operation, weil er keine bestehenden SHA-Hashes veraendert. Long-Running-Branches wie develop oder release/2.4, die regelmaessig Updates aus main erhalten, sollten grundsaetzlich per Merge aktualisiert werden, nicht per Rebase, da ein wiederholtes Rebasen eines bereits geteilten Branches exakt die goldene Regel verletzt. Merge ist damit der Standardfall für alles, was über den eigenen lokalen Arbeitsbereich hinausgeht.

6. Wann Rebase die richtige Wahl ist

Rebase entfaltet seinen Wert vor allem lokal, bevor Code geteilt wird. Ein typisches Muster: Ein Entwickler arbeitet mehrere Tage an einem Feature-Branch, sammelt dabei Zwischen-Commits wie „WIP“, „Tippfehler behoben“ oder „Tests grün“ an, und möchte vor dem Oeffnen eines Pull Requests eine saubere, nachvollziehbare Commit-Reihe praesentieren. Mit git rebase -i (interaktiv) lassen sich Commits zusammenfassen (squash), umformulieren (reword) oder umsortieren, bevor der Branch ueberhaupt zum ersten Mal gepusht wird.

Rebase eignet sich ebenso, um einen lokalen Feature-Branch auf den aktuellen Stand von main zu bringen, solange dieser Feature-Branch noch nicht geteilt wurde. Das Ergebnis ist eine lineare Historie ohne Merge-Commits, die sich mit git log deutlich einfacher lesen laesst als eine verflochtene Merge-Topologie mit vielen Nebenaesten. Teams, die grossen Wert auf eine linear lesbare Historie legen, etwa für git bisect bei der Fehlersuche, profitieren besonders davon, Feature-Branches konsequent vor dem Merge in main zu rebasen und zu bereinigen.

Fuer komplexere Faelle bietet git rebase --onto zusaetzliche Praezision: Statt einen ganzen Branch auf eine neue Basis zu setzen, laesst sich damit ein bestimmter Commit-Bereich gezielt herausschneiden und auf einer anderen Basis erneut abspielen, etwa wenn ein Feature-Branch versehentlich von einem anderen Feature-Branch statt von main abgezweigt wurde. Beim Aufraeumen der lokalen Historie hilft ausserdem interaktives Rebasen mit git rebase -i, bei dem einzelne Commits per Textdatei zusammengefasst, umbenannt oder geloescht werden können, bevor der Branch das erste Mal gepusht wird.

# Interactive rebase: clean up local commits before opening a PR
git rebase -i HEAD~5
# In the editor: mark commits as "squash" or "reword" as needed

# rebase --onto: move a branch that was accidentally based on the wrong branch
# feature-b was branched from feature-a instead of main
git rebase --onto main feature-a feature-b
# Replays only the commits unique to feature-b onto main,
# skipping everything feature-a already contributed

Konflikte während eines Rebases behandelt Git anders als bei einem Merge: Statt eines einzigen Konfliktdurchgangs für die gesamte Aenderung können mehrere, unabhaengige Konflikte nacheinander auftreten, einer pro betroffenem Commit. Der Rebase-Prozess pausiert bei jedem konfliktbehafteten Commit einzeln und wartet auf eine manuelle Aufloesung, bevor er mit dem naechsten Commit fortfaehrt.

# Resolving a conflict that occurs mid-rebase
git rebase origin/main
# CONFLICT (content): Merge conflict in src/Checkout/Cart.php
git status
# Manually edit src/Checkout/Cart.php to resolve the conflict markers
git add src/Checkout/Cart.php
git rebase --continue

# Repeats for each subsequent commit that conflicts

# Abort at any point to return to the pre-rebase state
git rebase --abort

7. Fast-Forward-Merges, --no-ff und der Bezug zu Rebase

Ein Fast-Forward-Merge tritt auf, wenn der Ziel-Branch seit der Verzweigung keine neuen eigenen Commits erhalten hat. In diesem Fall muss Git gar keinen Drei-Wege-Merge durchfuehren, sondern verschiebt den Branch-Zeiger einfach vorwaerts auf den letzten Commit des Feature-Branches. Es entsteht kein Merge-Commit, die Historie bleibt vollstaendig linear, fast so, als haette man direkt auf dem Ziel-Branch gearbeitet.

Mit dem Flag --no-ff erzwingt man auch in dieser Situation einen expliziten Merge-Commit, um die Tatsache der Integration in der Historie sichtbar zu dokumentieren, selbst wenn technisch ein Fast-Forward moeglich waere. Viele Teams nutzen --no-ff gezielt für Feature-Branches, um spaeter erkennen zu können, welche Commits zu welchem Feature gehoerten. Der Bezug zu Rebase: Wer einen Feature-Branch vor dem Merge auf den aktuellen main-Stand rebast, sorgt dafuer, dass der anschliessende Merge fast immer ein Fast-Forward ist, weil keine Divergenz mehr besteht. Rebase und Fast-Forward-Merge sind damit haeufig zwei Haelften desselben Workflows: erst lokal linearisieren, dann sauber integrieren.

# Fast-forward merge: branch pointer simply moves forward
git checkout main
git merge feature/small-fix
# Fast-forward, no merge commit created

# Force an explicit merge commit even when fast-forward is possible
git merge --no-ff feature/small-fix
# Creates a merge commit documenting the integration point

# Rebase-then-merge pattern: linearize locally, then fast-forward
git checkout feature/checkout-redesign
git rebase origin/main
git checkout main
git merge feature/checkout-redesign

8. Praktischer Entscheidungsrahmen für den Alltag

Die Entscheidung zwischen Merge und Rebase laesst sich auf eine einzige Leitfrage reduzieren: Wurde dieser Branch bereits geteilt? Ist die Antwort ja, gilt die goldene Regel und Merge ist die sichere Operation. Ist die Antwort nein, es handelt sich also um einen rein lokalen Arbeitsstand, ist Rebase eine legitime und oft die sauberere Wahl, um die Historie vor der Veroeffentlichung aufzuraeumen.

Eine dritte Option, die in diesem Entscheidungsrahmen oft uebersehen wird, ist git merge --squash: Alle Commits eines Feature-Branches werden zu einer einzigen Aenderung zusammengefasst und als ein Commit auf den Ziel-Branch angewendet, ohne die urspruenglichen Commits oder eine Merge-Beziehung zu erhalten. Squash-Merges eignen sich besonders für Pull-Request-Workflows, bei denen die interne Commit-Historie eines Features für die Nachwelt uninteressant ist und nur das Endergebnis pro Feature in main sichtbar sein soll. GitHub- und GitLab-Oberflaechen bieten „Squash and Merge“ standardmaessig als dritten Button neben „Merge“ und „Rebase and Merge“ an, genau aus diesem Grund.

9. Typische Stolperfallen und Merge vs. Rebase im Vergleich

Der haeufigste Fehler in der Praxis ist der Force-Push nach einem Rebase auf einem Branch, den Kollegen bereits ausgecheckt haben. Statt git push --force sollte in Teams, in denen ein Rebase auf einem bereits geteilten, aber ausschließlich selbst genutzten Feature-Branch noetig ist, immer git push --force-with-lease verwendet werden. Dieses Flag bricht den Push ab, wenn der Remote-Branch seit dem letzten eigenen Fetch von jemand anderem veraendert wurde, und verhindert so, dass fremde Commits versehentlich ueberschrieben werden.

Ein zweiter typischer Fehler: Rebase auf einen Branch mit bereits abgeschlossenen, gemergten Pull Requests anwenden und dadurch Commits duplizieren, weil Git dieselbe inhaltliche Aenderung nicht als bereits vorhanden erkennt. Ein dritter Stolperstein ist das Ignorieren von Merge-Konflikten bei einem Rebase mit vielen Commits: Wer bei jedem einzelnen Konflikt hastig git add . ohne pruefenden Blick ausfuehrt, riskiert, versehentlich fehlerhafte Aufloesungen dauerhaft in die Historie zu uebernehmen. Die folgende Tabelle stellt beide Operationen entlang der wichtigsten Entscheidungsdimensionen gegenueber.

10. Zusammenfassung

Die Entscheidung zwischen Merge und Rebase ist keine Geschmacksfrage, sondern haengt direkt davon ab, ob die betroffene Historie bereits geteilt wurde. git merge erstellt einen Merge-Commit mit zwei Eltern und veraendert keine bestehenden Commits, was ihn zur sicheren Wahl für geteilte, langlebige Branches macht. git rebase spielt Commits auf einer neuen Basis erneut ab und erzeugt dabei neue SHA-Hashes, was ihn ideal für die lokale Aufraeumung vor dem ersten Push macht, aber gefaehrlich auf bereits gepushten Branches.

Die goldene Regel, niemals Commits zu rebasen, die andere bereits ausgecheckt haben, ist der wichtigste Merksatz in diesem gesamten Themenfeld. Fast-Forward-Merges und Rebase ergaenzen sich haeufig: erst lokal linearisieren, dann sauber per Fast-Forward integrieren. Wer zusaetzlich merge --squash für Pull-Request-Workflows in Betracht zieht, hat alle drei praktischen Werkzeuge für eine saubere, nachvollziehbare Git-Historie im Team beisammen.

11. FAQ: Merge vs. Rebase