Git merge vs rebase: Was passt zu Ihrem Team?

Kurz gesagt: der Unterschied zwischen merge und rebase

Bei der Debatte „merge vs rebase“ geht es eigentlich nicht darum, welcher Befehl besser ist, sondern darum, welche Projekthistorie Sie sehen möchten. Beide Befehle führen am Ende zum selben Code. Unterschiedlich ist nur der Weg, der im Log festgehalten wird.

• Merge verbindet zwei Entwicklungslinien und dokumentiert ehrlich, dass parallel gearbeitet wurde. Bestehende Commits bleiben unverändert, hinzu kommt ein Merge-Commit mit zwei Eltern.
• Rebase schreibt Ihre Commits so um, als hätten Sie Ihre Arbeit auf dem neuesten Stand des Basis-Branches begonnen. Die Historie wirkt wie eine gerade Linie, aber die Commits bekommen neue Hashes.

Die Mechanik der einzelnen Befehle – Optionen, Konfliktlösung, interaktiver Modus – behandeln wir in eigenen Artikeln. Hier geht es nur um die Wahl der Strategie.

So sieht die Historie in beiden Fällen aus

Ausgangslage: Sie haben feature abgezweigt und zwei Commits gemacht, in der Zwischenzeit sind in main zwei Commits von Kollegen dazugekommen.

          D---E        feature
         /
A---B---C---F---G      main

Nach git merge feature in main:

          D---E
         /     \
A---B---C---F---G---M  main

Nach git rebase main in feature und anschließendem Fast-Forward von main:

A---B---C---F---G---D'---E'   main

Im ersten Fall sieht man in der Historie, dass das Feature parallel entwickelt wurde und wann es integriert wurde. Im zweiten liest sich die Historie wie eine fortlaufende Erzählung, aber die parallele Arbeit ist nicht mehr erkennbar: D' und E' sind neue Commits, die beim rebase entstanden sind.

Vergleichstabelle merge vs rebase

Vor- und Nachteile von merge

Vorteile

• Zerstört keine Historie. Alles, was veröffentlicht wurde, bleibt, wo es ist. Ihre Kollegen müssen nach Ihrer Aktion nichts reparieren.
• Konflikte werden einmal gelöst. Selbst wenn der Branch 30 Commits hat, kümmern Sie sich um den Endstand und nicht um jeden einzelnen Schritt.
• Der Kontext bleibt erhalten. Am Merge-Commit sieht man, welche Aufgabe wann im Haupt-Branch gelandet ist, und kann sie problemlos als Ganzes zurücknehmen.

Nachteile

• Unruhiger Graph. Bei häufigem Synchronisieren sammeln sich Commits wie „Merge branch 'main' into feature“, und git log --graph wird zum Gleisplan.
• Entwurfs-Commits landen in der Historie. „wip“, „fix“, „noch ein fix“ bleiben für immer im Haupt-Branch, wenn man sie nicht zusammenfasst.

Vor- und Nachteile von rebase

Vorteile

• Lineare, gut lesbare Historie. Jeder Commit steht an seinem Platz, git log liest sich wie eine Änderungsliste, und git bisect findet den fehlerhaften Commit leichter.
• Commits lassen sich vor dem Review aufräumen: zusammenfassen, umbenennen, umsortieren.
• Keine technischen Merge-Commits durch das Synchronisieren mit dem Haupt-Branch.

Nachteile

• Schreibt die Historie um. Ein rebase auf einem bereits veröffentlichten gemeinsamen Branch bringt allen, die ihn geholt haben, die Arbeit durcheinander.
• Erfordert Force-Push für Branches auf dem Server – und damit Disziplin und --force-with-lease.
• Wiederkehrende Konflikte. Dieselbe Stelle kann bei mehreren Commits hintereinander in Konflikt geraten.
• Zwischen-Commits bauen eventuell nicht. Nach dem Verschieben auf eine neue Basis hat niemand die alten Commits in der neuen Umgebung getestet.

Wann nimmt man was?

Rebase – für die eigene lokale Arbeit

Sie aktualisieren Ihren Branch vor dem Push – git pull --rebase. Sie bereiten einen Branch fürs Review vor und wollen Entwurfs-Commits loswerden – git rebase -i. Ihr persönlicher Feature-Branch hinkt main hinterher – git rebase origin/main. In all diesen Fällen werden Commits umgeschrieben, die nur Sie gesehen haben (oder die nur Ihnen gehören).

Merge – für gemeinsame Branches und Integration

Ein fertiges Feature wird in main oder develop integriert. An einem Branch arbeiten mehrere Personen. Ein Release-Branch soll zurück in den Haupt-Branch. Hier dürfen bereits veröffentlichte Commits nicht angefasst werden, und merge ist die einzig korrekte Option.

Die einfache Faustregel

Wenn nur Sie die Commits haben – rebase ist erlaubt. Wenn sie schon jemand geholt hat – nur merge.

Bewährte Workflows für Teams

Auf GitHub und GitLab entsprechen diese Workflows den Buttons „Create a merge commit“, „Rebase and merge“ und „Squash and merge“. Erlauben Sie in den Repository-Einstellungen am besten nur die gewählte Variante, damit die Historie kein Stilmix wird.

Einstellungen, die die Wahl festschreiben

# pull ohne überflüssige Merge-Commits
git config --global pull.rebase true

# oder: pull nur per Fast-Forward, sonst Fehler – Sie entscheiden selbst
git config --global pull.ff only

# beim Integrieren von Features immer einen Merge-Commit erzeugen
git config --global merge.ff false

Vorsicht bei merge.ff false: Die Einstellung wirkt auch auf git pull im Merge-Modus. Viele setzen sie deshalb nicht global, sondern geben beim Integrieren eines Features explizit --no-ff an.

Beispiel: dieselbe Aufgabe in zwei Stilen

Ein realistisches Szenario: Sie arbeiten drei Tage am Payment-Feature im Branch feature/payment, in der Zeit wurden fünf fremde Aufgaben in main integriert. Vor dem Pull Request müssen Sie den aktuellen main einbeziehen und prüfen, ob alles funktioniert.

Variante mit merge

git switch feature/payment
git fetch origin
git merge origin/main
# Konflikte einmal gelöst, git add, git commit
git push

Der Branch hat einen Commit „Merge remote-tracking branch 'origin/main' into feature/payment“ bekommen. Der Push läuft ganz normal, Kollegen, die den Branch angesehen haben, merken nichts. Wenn Sie so jeden Tag synchronisieren, enthält der Branch drei solche Commits, und ohne Squash landen sie zusammen mit dem Feature in main.

Variante mit rebase

git switch feature/payment
git fetch origin
git rebase origin/main
# Konflikte werden unterwegs gelöst, bei jedem Commit: git add, git rebase --continue
git rebase -i origin/main      # optional: Entwurfs-Commits zusammenfassen
git push --force-with-lease

Der Branch sieht aus, als wäre er heute Morgen vom aktuellen main abgezweigt worden, überflüssige Commits gibt es nicht, und der Reviewer kann die Änderungen Schritt für Schritt leichter nachvollziehen. Der Preis: ein Force-Push und die Pflicht, darauf zu achten, dass niemand sonst in diesen Branch committet.

Was am Ende in main ankommt

Bei der Integration per Pull Request bleibt der Unterschied bestehen. Der Merge-Stil ergibt einen Graphen mit Abzweigungen und Synchronisations-Merges, der Rebase-Stil eine saubere Kette von Feature-Commits, die per Fast-Forward oder mit einem einzigen Merge-Commit integriert werden kann. Der Code ist dabei identisch, sofern die Konflikte gleich gelöst wurden.

So trifft das Team die Entscheidung

Beantworten Sie ein paar Fragen. Arbeiten mehrere Personen im selben Branch? Dann scheidet rebase für diesen Branch aus. Wie erfahren ist das Team mit Git? Gibt es viele Einsteiger, beginnen Sie mit merge und Squash-Merge – sie verzeihen Fehler. Brauchen Sie eine lückenlose Chronologie für Audits und Incident-Analysen? Dann sind Merge-Commits für Features nützlich. Sind ein lesbares git log und häufiges git bisect wichtig? Dann spricht das für rebase und eine lineare Historie.

Halten Sie die Entscheidung in CONTRIBUTING oder README des Repositorys fest und aktivieren Sie den Schutz des Haupt-Branches: kein Force-Push, Pull Request verpflichtend, festgelegte Merge-Methode. Eine Regel, die über Einstellungen erzwungen wird, funktioniert zuverlässiger als jede mündliche Absprache.

Verbreitete Irrtümer

• „Rebase ist für Fortgeschrittene, merge für Anfänger.“ Nein: Es sind verschiedene Werkzeuge für verschiedene Aufgaben. Erfahrene Entwickler nutzen beide.
• „Merge-Commits sind Müll.“ Synchronisations-Merges – ja, oft Rauschen. Aber der Merge-Commit, mit dem ein Feature integriert wird, ist ein nützlicher Ankerpunkt: Darüber sieht man eine ganze Aufgabe und kann sie zurücknehmen.
• „Nach einem rebase gibt es weniger Konflikte.“ Die Konflikte sind dieselben, denn es werden dieselben Zeilen geändert. Rebase verteilt sie nur auf die einzelnen Commits, merge löst sie in einem Rutsch.
• „Rebase verliert Commits.“ Die alten Commits bleiben im git reflog und lassen sich wiederherstellen, solange die Garbage Collection sie nicht entfernt hat.

Fazit

Die Entscheidung merge vs rebase ist eine Entscheidung zwischen ehrlicher Chronologie und gut lesbarer linearer Historie. Merge ist sicher und bewahrt den Kontext, rebase sorgt für Ordnung, schreibt aber Commits um. Am zuverlässigsten ist die Kombination: den eigenen Branch rebasen und aufräumen, solange er Ihnen gehört, und fertige Arbeit nach den Teamregeln per merge oder squash in gemeinsame Branches integrieren. Entscheidend ist, sich auf einen Workflow zu einigen und ihn in den Repository-Einstellungen festzuschreiben. Beide Strategien und die Arbeit mit Branches im Team werden im Git-Kurs praktisch geübt.