Kaum eine Frage löst in Entwicklerteams so viele Grundsatzdiskussionen aus wie diese: merge oder rebase? Beide Git-Befehle dienen demselben Zweck – sie führen die Arbeit aus zwei Branches zusammen. Doch sie tun das auf völlig unterschiedliche Weise und hinterlassen einen jeweils ganz anderen Projektverlauf. Wer den Unterschied versteht, trifft nicht nur sauberere Entscheidungen im Alltag, sondern vermeidet auch die gefürchteten Momente, in denen plötzlich Commits doppelt auftauchen oder ein geteilter Branch zerschossen ist. Dieser Ratgeber erklärt beide Verfahren von Grund auf, zeigt ihre Stärken und Schwächen und gibt dir eine klare Faustregel für die tägliche Arbeit.
Worum es bei beiden Befehlen eigentlich geht
Stell dir vor, du arbeitest an einem Feature-Branch, während gleichzeitig Kolleginnen und Kollegen Änderungen in den Hauptbranch (oft main oder develop) einspielen. Dein Branch und der Hauptbranch laufen also auseinander. Irgendwann willst du diese beiden Entwicklungslinien wieder vereinen. Genau hier kommen git merge und git rebase ins Spiel. Der zentrale Unterschied: Merge verbindet die beiden Linien an einem Punkt und behält beide Verläufe bei. Rebase nimmt deine Commits, hebt sie gedanklich an und setzt sie neu auf der aktuellen Spitze des anderen Branches auf, als hättest du von Anfang an dort gearbeitet.
Wie merge den Verlauf bewahrt
Beim Merge bleibt die Geschichte exakt so erhalten, wie sie tatsächlich passiert ist. Git nimmt die letzten Commits beider Branches, sucht ihren gemeinsamen Vorfahren und erzeugt in der Regel einen zusätzlichen Commit – den sogenannten Merge-Commit. Dieser hat zwei Eltern-Commits und markiert genau die Stelle, an der die beiden Linien wieder zusammenfanden. Dadurch ist im Nachhinein klar erkennbar, dass ein eigenständiger Branch existierte und wann er integriert wurde.
- Verlauf bleibt unverändert: Kein Commit wird umgeschrieben, alle ursprünglichen Hashes bleiben gleich.
- Nachvollziehbarkeit: Man sieht, welche Commits zu welchem Feature gehörten und wann sie zusammengeführt wurden.
- Sicherer bei Teamarbeit: Da nichts neu geschrieben wird, entstehen keine Konflikte mit bereits veröffentlichten Commits.
Der Preis dafür ist ein Verlauf, der schnell verzweigt und unübersichtlich werden kann. In Projekten mit vielen parallelen Branches entsteht eine Art „Gleisplan" aus sich kreuzenden Linien, der in der grafischen Ansicht überladen wirkt.
Wie rebase einen linearen Verlauf schafft
Rebase verfolgt die gegenteilige Philosophie. Statt einen Verbindungs-Commit zu erzeugen, schreibt Git deine Commits neu: Es löst sie vom alten Ausgangspunkt, holt die neuen Commits des Zielbranches und wendet anschließend deine Änderungen einzeln darüber an. Das Ergebnis ist eine schnurgerade, lineare Historie ohne Verzweigungen – so, als wäre alles nacheinander auf einer einzigen Linie entstanden.
Wichtig ist dabei: Die neu angewendeten Commits sind technisch gesehen nicht mehr dieselben. Sie bekommen neue Hashes, weil sich ihr Vorgänger geändert hat. Genau diese Eigenschaft macht Rebase mächtig, aber auch gefährlich, wenn man unvorsichtig ist.
- Saubere, gerade Historie: Ideal für ein
git log, das wie eine lesbare Erzählung wirkt. - Keine Merge-Commits: Der Verlauf bleibt frei von „Rauschen" durch automatische Verbindungs-Commits.
- Commits werden neu erzeugt: Alte Hashes verschwinden, was bei geteilten Branches zum Problem wird.
Die goldene Regel: niemals geteilte Branches rebasen
Wenn du nur eine Faustregel aus diesem Artikel mitnimmst, dann diese: Rebase nur Commits, die noch niemand anderes hat. Sobald du einen Branch gepusht hast und andere darauf aufbauen, ist ein Rebase tabu. Der Grund ist die schon erwähnte Neuvergabe der Hashes. Rebaset du einen geteilten Branch und pusht das Ergebnis, weicht deine Historie von der ab, die deine Kollegen lokal haben. Beim nächsten Pull entsteht ein heilloses Durcheinander mit doppelten Commits und Konflikten, die schwer aufzulösen sind.
Für lokale, noch nicht veröffentlichte Branches dagegen ist Rebase ein hervorragendes Werkzeug, um vor dem Pushen aufzuräumen. Halte dir merken:
- Lokal und nur von dir genutzt? Rebase ist erlaubt und oft sinnvoll.
- Bereits gepusht und von anderen genutzt? Finger weg vom Rebase – merge stattdessen.
- Du musst doch einen geteilten Branch umschreiben? Sprich es vorher mit dem Team ab und nutze
--force-with-leasemit Bedacht.
Konflikte: gleicher Ursprung, andere Behandlung
Ein verbreitetes Missverständnis lautet, Rebase oder Merge würden Konflikte vermeiden. Das stimmt nicht: Konflikte entstehen immer dann, wenn dieselben Zeilen in beiden Linien unterschiedlich geändert wurden – unabhängig vom gewählten Befehl. Der Unterschied liegt darin, wie und wann du sie auflöst.
Beim Merge erscheinen alle Konflikte gebündelt in einem einzigen Schritt. Du löst sie auf, erstellst den Merge-Commit, und die Sache ist erledigt. Beim Rebase werden deine Commits dagegen einzeln neu angewendet. Tritt ein Konflikt auf, hältst du an genau diesem Commit, löst ihn auf und setzt mit git rebase --continue fort. Bei vielen Commits kann derselbe Konflikt mehrfach auftauchen, was den Prozess mühsamer macht. Dafür bleibt am Ende eine saubere Historie übrig.
Fast-forward: der Sonderfall ohne Merge-Commit
Nicht jeder Merge erzeugt einen Merge-Commit. Hat sich der Zielbranch seit dem Abzweig nicht verändert, kann Git einen sogenannten Fast-forward-Merge durchführen. Dabei wird der Zeiger des Zielbranches einfach nach vorn auf die Spitze deines Branches geschoben – es entsteht kein zusätzlicher Commit, und das Ergebnis ist linear. Das passiert typischerweise, wenn du allein an einem kurzlebigen Branch arbeitest und der Hauptbranch in der Zwischenzeit unberührt blieb.
Möchtest du trotzdem immer einen Merge-Commit zur Dokumentation erzwingen, nutzt du git merge --no-ff. Umgekehrt kannst du mit --ff-only festlegen, dass ein Merge nur durchgeführt wird, wenn ein Fast-forward möglich ist. Viele Teams kombinieren diese Optionen mit ihren Branch-Regeln, um den gewünschten Verlauf zu erzwingen.
Direkter Vergleich auf einen Blick
Die folgende Tabelle fasst die wichtigsten Eigenschaften beider Verfahren zusammen und hilft dir, im Alltag schnell die passende Wahl zu treffen.
| Eigenschaft | git merge | git rebase |
|---|---|---|
| Verlaufsform | Verzweigt, zeigt parallele Linien | Linear, eine gerade Linie |
| Merge-Commit | Ja, außer bei Fast-forward | Nein, keiner |
| Commits umgeschrieben | Nein, Hashes bleiben gleich | Ja, neue Hashes |
| Risiko bei geteilten Branches | Gering, sicher | Hoch, kann Historie zerstören |
| Konfliktlösung | Einmalig, gebündelt | Pro Commit, eventuell mehrfach |
| Nachvollziehbarkeit | Hoch, zeigt echte Geschichte | Geringer, idealisierte Geschichte |
| Empfohlener Einsatz | Öffentliche/geteilte Branches | Lokale Branches aufräumen |
Welche Strategie passt zu deinem Team?
Es gibt keine universell richtige Antwort, sondern bewährte Muster. Viele Teams setzen auf eine Kombination: Lokal wird vor dem Push per Rebase aufgeräumt, damit die eigenen Commits sauber und logisch sortiert sind. Die Integration eines fertigen Feature-Branches in den Hauptbranch erfolgt dann per Merge – häufig sogar mit erzwungenem Merge-Commit, damit später klar erkennbar bleibt, welche Commits zu welchem Feature gehörten. Andere Teams bevorzugen eine strikt lineare Historie und nutzen beim Pull-Request einen „Squash-and-Merge", der alle Commits eines Branches zu einem einzigen zusammenfasst. Entscheidend ist, dass sich das Team auf eine Konvention einigt und sie konsequent durchhält. Wer regelmäßig mit Versionskontrolle arbeitet, findet auf unseren News-Artikeln weitere praxisnahe Anleitungen, und unter kostenlosen Webtools nützliche Helfer für den Entwickleralltag.
Häufige Fragen
Ist Rebase grundsätzlich besser als Merge?
Nein. Beide haben ihre Berechtigung. Rebase liefert eine sauberere Historie, ist aber riskant bei geteilten Branches. Merge ist sicherer und dokumentiert die echte Entwicklungsgeschichte. Die richtige Wahl hängt vom Kontext ab, nicht von einer pauschalen Überlegenheit.
Was passiert, wenn ich einen bereits gepushten Branch rebase?
Die Commits bekommen neue Hashes, wodurch deine Historie von der deiner Kollegen abweicht. Beim Pushen musst du erzwingen, und andere erleben beim nächsten Pull doppelte Commits und Konflikte. Deshalb gilt die Regel, geteilte Branches nicht zu rebasen.
Kann ich Konflikte durch die Wahl des Befehls vermeiden?
Nein. Konflikte entstehen durch widersprüchliche Änderungen an denselben Stellen, unabhängig davon, ob du merge oder rebase nutzt. Der Befehl bestimmt nur, ob du die Konflikte einmal gebündelt oder Commit für Commit auflöst.
Was ist ein Fast-forward-Merge genau?
Ein Fast-forward passiert, wenn der Zielbranch seit dem Abzweig unverändert blieb. Git verschiebt dann einfach den Branch-Zeiger nach vorn, ohne einen Merge-Commit zu erzeugen. Das Ergebnis ist eine lineare Historie ganz ohne Verzweigung.
Wie mache ich einen versehentlichen Rebase rückgängig?
Solange du nichts gepusht hast, hilft git reflog. Dort findest du den Zustand vor dem Rebase und kannst mit git reset --hard auf den entsprechenden Eintrag zurückspringen. Das Reflog protokolliert lokale Bewegungen des HEAD und ist dein Sicherheitsnetz.
Sollte ich als Anfänger lieber merge oder rebase nutzen?
Für den Einstieg ist merge die sicherere Wahl, weil es keine Commits umschreibt und damit schwerer etwas kaputtgeht. Rebase lohnt sich, sobald du verstanden hast, wie Git Commits intern verwaltet und wann das Umschreiben gefahrlos ist.