Git Rebase: Än­de­run­gen an die Spitze eines Branches setzen

Git Rebase in­te­griert Än­de­run­gen von einem Branch in einen anderen. Der Git-Command bietet mehr Mög­lich­kei­ten als Git Merge, sollte al­ler­dings mit Vorsicht genutzt werden.

Eine ent­schei­den­de Be­son­der­heit der Arbeit mit Git ist die Mög­lich­keit, im Team oder alleine parallel an un­ter­schied­li­chen Stellen eines Projekts zu arbeiten, Än­de­run­gen vor­zu­neh­men, Probleme zu beheben und dann die ge­won­ne­nen Er­kennt­nis­se wieder für das große Ganze nutzbar zu machen. Dies funk­tio­niert zum einen über den Einsatz von lokalen Re­po­si­to­ries und zum anderen – eine Stufe darunter – durch die Ver­wen­dung von Ab­zwei­gun­gen, also so­ge­nann­ten 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 al­ler­dings die Än­de­run­gen von einem Branch in einen anderen in­te­grie­ren, bietet das Ver­si­ons­kon­troll­sys­tem zwei Optionen.

Git Merge und Git Rebase eignen sich beide für die Zu­sam­men­füh­rung, un­ter­schei­den sich al­ler­dings auch deutlich von­ein­an­der. Git Rebase gilt als die an­spruchs­vol­le­re Lösung. Bei diesem Git Command wird eine Reihe von Commits in einen neuen Basis-Commit ver­scho­ben. 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 un­ter­schei­det bei Git Rebase zwischen einem manuellen und einem in­ter­ak­ti­ven Ansatz.

Um die genaue Funk­ti­ons­wei­se 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 prak­ti­schen Git Cheat Sheet mit PDF-Download finden – rufen wir im folgenden Beispiel den Branch „neu“ auf, den wir mit Git Rebase in den Master in­te­grie­ren wollen. Das funk­tio­niert dann ganz einfach über den ent­spre­chen­den 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 um­ge­schrie­ben.

Beim oben gezeigten Beispiel handelt es sich um die Stan­dard­ver­si­on von Git Rebase. Dabei wird der Befehl au­to­ma­tisch im aktuell aus­ge­wähl­ten Branch aus­ge­führt und auf den Branch-HEAD (in diesem Fall „master“) an­ge­wen­det. Sämtliche Commits werden dabei ver­scho­ben und an die Spitze des neuen Branches gesetzt. Die in­ter­ak­ti­ve Variante von Git Rebase bietet Ihnen weitere nützliche Optionen. So können Sie dabei jeden einzelnen Commit auswählen, ändern, ver­schie­ben oder löschen. Das gibt Ihnen die Mög­lich­keit, den Verlauf nach Ihren Vor­stel­lun­gen auf­zu­räu­men und unter Umständen zu op­ti­mie­ren. Der Befehl sieht dabei fast aus wie die Stan­dard­ver­si­on, enthält al­ler­dings den kleinen Zusatz „--i“:

Wenn Sie diesen Befehl ausführen, öffnet sich au­to­ma­tisch ein Editor, in dem Sie eine Auf­lis­tung sämt­li­cher Commits erhalten und diese nach eigenen Vor­stel­lun­gen anpassen können.

Für fort­ge­schrit­te­ne Nut­ze­rin­nen und Nutzer bietet Git Rebase weitere nützliche Optionen. Dies sind die wich­tigs­ten:

In vielen Punkten ähnelt Git Rebase also Git Merge. Beide Befehle in­te­grie­ren Än­de­run­gen eines Branches in einen anderen. Git Merge lässt die be­stehen­den Branches dabei völlig unberührt. Das ist vor­teil­haft, da die gesamte History erhalten bleibt. Al­ler­dings entstehen so auch viele unnötige Merge-Commits. Git Rebase ist die lineare Lösung, die durch den in­ter­ak­ti­ven Ansatz viele An­pas­sungs­op­tio­nen bietet, jedoch als Option für Fort­ge­schrit­te­ne gilt.

Git Rebase bietet einen großen Vorteil und einen po­ten­zi­el­len Nachteil. Der positive Effekt dieses Befehls ist die saubere und über­sicht­li­che History Ihres Projekts. Diese ist durch Git Rebase völlig linear aufgebaut und ver­zich­tet von der Spitze bis zum Anfang auf sämtliche Forks. Das er­leich­tert die Na­vi­ga­ti­on und hält das gesamte Projekt schlank. Diese Re­du­zie­rung bewirkt al­ler­dings auch, dass die Rück­ver­folg­bar­keit nicht mehr unbedingt gegeben ist. Commits können verloren gehen, was gerade bei der Arbeit in einem größeren Team zu Merge-Kon­flik­ten führen kann. Git Rebase ist daher ein sehr wir­kungs­vol­ler und nütz­li­cher Befehl, der jedoch mit Bedacht ein­ge­setzt werden sollte.

Das bedeutet vor allem auch, dass Sie Git Rebase nicht auf öf­fent­li­chen Branches einsetzen. Ansonsten würden Sie nämlich den Main-Branch zwar in Ihr lokales Re­po­si­to­ry ein­glie­dern, Ihre Team­mit­glie­der würden al­ler­dings auf einer völlig anderen Version wei­ter­ar­bei­ten. Es wäre daher sehr schwierig oder viel­leicht sogar unmöglich, am Ende wieder alle losen Enden zu­sam­men­zu­füh­ren und zu syn­chro­ni­sie­ren.