Git Rebase: Änderungen an die Spitze eines Branches setzen

Git Rebase integriert Änderungen von einem Branch in einen anderen. Der Git-Command bietet mehr Möglichkeiten als Git Merge, sollte allerdings mit Vorsicht genutzt werden.

Eine entscheidende Besonderheit der Arbeit mit Git ist die Möglichkeit, im Team oder alleine parallel an unterschiedlichen Stellen eines Projekts zu arbeiten, Änderungen vorzunehmen, Probleme zu beheben und dann die gewonnenen Erkenntnisse wieder für das große Ganze nutzbar zu machen. Dies funktioniert zum einen über den Einsatz von lokalen Repositories und zum anderen – eine Stufe darunter – durch die Verwendung von Abzweigungen, also sogenannten Branches. In diesen können Sie autark an einer Änderung arbeiten und üben zunächst keinen Einfluss auf das restliche Projekt aus. Möchten Sie dann allerdings die Änderungen von einem Branch in einen anderen integrieren, bietet das Versionskontrollsystem zwei Optionen.

Git Merge und Git Rebase eignen sich beide für die Zusammenführung, unterscheiden sich allerdings auch deutlich voneinander. Git Rebase gilt als die anspruchsvollere Lösung. Bei diesem Git Command wird eine Reihe von Commits in einen neuen Basis-Commit verschoben. Dadurch ändert sich die Basis dieses Commits und ein gesamter Branch wird dabei an die Spitze eines anderen Zweigs gesetzt. Dazu schreibt Git Rebase die History des Projekts neu, da für die Commits im Original-Branch neue Commits erstellt werden. Man unterscheidet bei Git Rebase zwischen einem manuellen und einem interaktiven Ansatz.

Um die genaue Funktionsweise von Git Rebase zu verstehen, lohnt sich zunächst ein Blick auf die Syntax. Diese ist relativ schnell erklärt. Über Git Checkout – einen Befehl, den Sie auch im praktischen Git Cheat Sheet mit PDF-Download finden – rufen wir im folgenden Beispiel den Branch „neu“ auf, den wir mit Git Rebase in den Master integrieren wollen. Das funktioniert dann ganz einfach über den entsprechenden Command, bei dem wir lediglich den Ziel-Branch angeben müssen. So sieht das aus:

So wird nun der Branch „neu“ an die Spitze des Master-Branches gesetzt und die Projekt-History umgeschrieben.

Beim oben gezeigten Beispiel handelt es sich um die Standardversion von Git Rebase. Dabei wird der Befehl automatisch im aktuell ausgewählten Branch ausgeführt und auf den Branch-HEAD (in diesem Fall „master“) angewendet. Sämtliche Commits werden dabei verschoben und an die Spitze des neuen Branches gesetzt. Die interaktive Variante von Git Rebase bietet Ihnen weitere nützliche Optionen. So können Sie dabei jeden einzelnen Commit auswählen, ändern, verschieben oder löschen. Das gibt Ihnen die Möglichkeit, den Verlauf nach Ihren Vorstellungen aufzuräumen und unter Umständen zu optimieren. Der Befehl sieht dabei fast aus wie die Standardversion, enthält allerdings den kleinen Zusatz „--i“:

Wenn Sie diesen Befehl ausführen, öffnet sich automatisch ein Editor, in dem Sie eine Auflistung sämtlicher Commits erhalten und diese nach eigenen Vorstellungen anpassen können.

Für fortgeschrittene Nutzerinnen und Nutzer bietet Git Rebase weitere nützliche Optionen. Dies sind die wichtigsten:

In vielen Punkten ähnelt Git Rebase also Git Merge. Beide Befehle integrieren Änderungen eines Branches in einen anderen. Git Merge lässt die bestehenden Branches dabei völlig unberührt. Das ist vorteilhaft, da die gesamte History erhalten bleibt. Allerdings entstehen so auch viele unnötige Merge-Commits. Git Rebase ist die lineare Lösung, die durch den interaktiven Ansatz viele Anpassungsoptionen bietet, jedoch als Option für Fortgeschrittene gilt.

Git Rebase bietet einen großen Vorteil und einen potenziellen Nachteil. Der positive Effekt dieses Befehls ist die saubere und übersichtliche History Ihres Projekts. Diese ist durch Git Rebase völlig linear aufgebaut und verzichtet von der Spitze bis zum Anfang auf sämtliche Forks. Das erleichtert die Navigation und hält das gesamte Projekt schlank. Diese Reduzierung bewirkt allerdings auch, dass die Rückverfolgbarkeit nicht mehr unbedingt gegeben ist. Commits können verloren gehen, was gerade bei der Arbeit in einem größeren Team zu Merge-Konflikten führen kann. Git Rebase ist daher ein sehr wirkungsvoller und nützlicher Befehl, der jedoch mit Bedacht eingesetzt werden sollte.

Das bedeutet vor allem auch, dass Sie Git Rebase nicht auf öffentlichen Branches einsetzen. Ansonsten würden Sie nämlich den Main-Branch zwar in Ihr lokales Repository eingliedern, Ihre Teammitglieder würden allerdings auf einer völlig anderen Version weiterarbeiten. Es wäre daher sehr schwierig oder vielleicht sogar unmöglich, am Ende wieder alle losen Enden zusammenzuführen und zu synchronisieren.