Git Rebase vs Merge: Wann nutzt man was

Die Wahl zwischen git rebase und git merge wird in den meisten Teams weit mehr diskutiert als verstanden. Beide vereinen die Arbeit zweier Branches; der Unterschied liegt darin, wie die Historie danach aussieht und wie man Konflikte handhabt. Dieser Artikel zeigt, was jeder Befehl tatsächlich tut, wann man zu welchem greift und welche klassischen Unfälle Teams passieren, alles mit konkreten Beispielen.

Beide leisten dasselbe, schreiben die Historie aber anders

Angenommen, Sie haben feature von main abgezweigt, und während Sie arbeiteten, ist main weitergewandert. Nun wollen Sie die neuen Commits aus main in Ihren Branch holen. Dafür gibt es zwei Wege.

Merge nimmt die Spitzen beider Branches und erzeugt einen neuen Merge-Commit. Ihre Commits bleiben unangetastet; die beiden Historien werden einfach an einem einzigen Punkt verknüpft:

git checkout feature
git merge main

Rebase legt Ihre Commits dagegen vorübergehend beiseite, verschiebt den Startpunkt Ihres Branches auf den neuesten Stand von main und wendet Ihre Commits einen nach dem anderen auf dieser neuen Basis erneut an:

git checkout feature
git rebase main

Das Ergebnis: Nach einem Merge verzweigt und vereint sich die Historie, während sie nach einem Rebase wie eine gerade Linie aussieht, als hätten Sie von Anfang an auf dem aktuellen main gearbeitet.

Rebase kopiert Commits, es verschiebt sie nicht

Das ist der entscheidende Punkt: Rebase verschiebt Ihre Commits nicht, es kopiert sie. Jeder erneut angewandte Commit erhält einen neuen Hash, denn obwohl sein Inhalt identisch ist, hängt er nun an einem anderen Parent. Die alten Commits bleiben noch eine Weile in Ihrem reflog bestehen, doch Ihr Branch zeigt jetzt auf die neuen Kopien.

Die praktische Folge ist groß: Rebase schreibt die Historie um. Auf einem lokalen Branch, den Sie mit niemandem geteilt haben, ist das völlig sicher. Tun Sie es aber auf einem geteilten Branch, den andere bereits gepullt haben, passt die Historie aller nicht mehr zu Ihrer. Das führt uns zur wichtigsten Regel.

Die goldene Regel: geteilte Historie niemals rebasen

Wenn Sie sich nur eine Regel merken, vermeiden Sie die meisten Probleme:

• Rebasen Sie bedenkenlos Branches, die nur Ihnen gehören, noch nicht gepusht wurden oder auf denen niemand Arbeit aufgebaut hat.
• Rebasen Sie niemals Branches, die alle teilen, wie main oder develop.

Haben Sie einen Feature-Branch rebased, den Sie bereits gepusht hatten, müssen Sie force-pushen, um das Remote zu aktualisieren. Bevorzugen Sie hier statt eines bloßen --force immer die sicherere Variante:

git push --force-with-lease

--force-with-lease verweigert den Push, wenn der Remote-Branch von dem abweicht, was Sie zuletzt gesehen haben (also wenn jemand zwischenzeitlich gepusht hat), damit Sie die Arbeit eines Teamkollegen nicht stillschweigend überschreiben. Ein einfaches --force bietet diesen Schutz nicht.

Konflikte: auf einmal oder Schritt für Schritt

Die Konfliktbehandlung unterscheidet sich deutlich zwischen beiden. Beim Merge treffen alle Änderungen an einem einzigen Punkt aufeinander; Sie lösen die Konflikte einmal, führen git add aus und schließen den Merge ab.

Beim Rebase können Konflikte, weil Ihre Commits der Reihe nach erneut angewandt werden, bei jedem Commit einzeln auftauchen. Berühren mehrere Ihrer Commits dieselbe Zeile, müssen Sie einen ähnlichen Konflikt womöglich mehrfach lösen. Der Ablauf sieht so aus:

# die konfligierenden Dateien beheben, dann:
git add <Datei>
git rebase --continue

# um diesen Commit zu überspringen:
git rebase --skip

# um alles abzubrechen und zurückzukehren:
git rebase --abort

Wird es unübersichtlich, bringt git rebase --abort Sie genau in den Zustand vor dem Rebase zurück; wenn Sie also feststecken, können Sie in Ruhe abbrechen und es erneut versuchen, statt in Panik zu geraten.

Die Historie mit interaktivem Rebase aufräumen

Die mächtigste Anwendung von Rebase ist nicht das Zusammenführen von Branches, sondern das Bearbeiten der eigenen Commit-Historie. Mit git rebase -i (interaktiv) können Sie vor dem Pushen Commits zusammenfassen, umsortieren oder ihre Nachrichten korrigieren:

git rebase -i HEAD~4

Im sich öffnenden Editor wählen Sie pro Commit einen Befehl: pick (so belassen), squash (mit dem vorherigen verschmelzen), reword (Nachricht ändern), drop (löschen). So fassen Sie ein Durcheinander aus "fix", "noch ein fix", "typo" Commits zu einem sinnvollen Commit zusammen und machen den Pull Request lesenswert. Auch das nur bei Commits, die Sie noch nicht geteilt haben.

Eine praktische Team-Strategie

Für die meisten Teams funktioniert ein hybrider Ansatz gut:

• Um Ihren Feature-Branch aktuell zu halten, rebasen Sie main in Ihren Branch (git rebase main), damit die Historie flach bleibt und sich keine unnötigen Merge-Commits ansammeln.
• Beim Einbringen des Feature-Branches in main nutzen Sie merge, oft mit --no-ff, damit "dieses Feature kam hier hinein" klar in einem einzigen Merge-Commit festgehalten bleibt.
• Bevor Sie den Pull Request öffnen, räumen Sie Ihre Commits mit git rebase -i auf.

Viele Teams integrieren PRs auch per "Squash and Merge": Das gesamte Feature landet als ein einziger Commit auf main. Das hält die main-Historie äußerst lesbar, wobei jede Zeile einem Feature entspricht. Welche Strategie Sie auch wählen, entscheidend ist, als Team konsistent zu sein; ein Team, in dem die eine Hälfte rebased und die andere merged, bekommt die schlechteste Historie von allen.

Häufig gestellte Fragen

Ist Rebase gefährlicher als Merge?

Es ist nicht gefährlich, es hat nur Regeln, weil es die Historie umschreibt. Auf lokalen, ungeteilten Branches ist Rebase völlig sicher und hält die Historie sauber. Die einzige echte Gefahr ist, einen geteilten Branch, den andere nutzen, zu rebasen und force-zu-pushen; solange Sie diese Regel nicht brechen, können Sie es frei einsetzen.

Wie breche ich einen Rebase ab, wenn ein Konflikt auftritt?

Der Befehl git rebase --abort bringt Sie genau in den Zustand vor dem Start des Rebase zurück. Sie verlieren keinen Commit, und auszusteigen, um stattdessen mit einem Merge weiterzumachen, ist eine völlig legitime Entscheidung, wenn Sie durcheinanderkommen.

Was tun, wenn ich meine Historie versehentlich zerstöre?

git reflog ist Ihr Sicherheitsnetz. Git bewahrt eine Weile jede alte Position auf, auf die Ihr Branch gezeigt hat; finden Sie den richtigen Hash im reflog und kehren Sie mit git reset --hard <Hash> zu diesem Moment zurück. Deshalb ist "die Historie umschreiben" weit weniger endgültig, als es klingt.

Möchten Sie den Git-Workflow Ihres Teams vereinfachen? Lassen Sie uns gemeinsam sinnvolle Branching-Strategien, CI/CD-Integration und eine saubere Commit-Historie aufsetzen. Nehmen Sie Kontakt auf und wir gestalten einen Workflow, der zu Ihrem Projekt passt.