Das Kommando git rebase ist ein Feature für fortgeschrittene Nutzer, das vielfältige Möglichkeiten bietet, aber mit Bedacht eingesetzt sein will. Nachdem wir uns im ersten Artikel mit konzeptionellen Fragen und den Möglichkeiten des interaktiven Rebasings beschäftigt haben, wollen wir nun betrachten, welche Regeln bei der Arbeit mit git rebase einzuhalten sind und wie sich der Befehl sinnvoll in unsere Entwicklungs-Workflows mit Git einbinden lässt.

Die goldene Regel des Rebasings

Wenn wir einmal verstanden haben, was Rebasing ist, müssen wir direkt lernen, wann wir es nicht tun dürfen. Die goldene Regel lautet, dass git rebase nie auf öffentlichen Branches genutzt werden darf.

Überlegen wir einmal, was beispielsweise geschehen würde, wenn wir den master auf unseren feature-Branch rebasen:

Rebasing des Master-Branchs

Das Rebasing bewegt alle Commits im master an die Spitze des feature-Branchs. Das Problem ist, dass dies nur in unserem Repository passiert. Alle anderen Entwickler arbeiten weiterhin mit dem ursprünglichen master. Da Rebasing zu brandneuen Commits führt, wird Git denken, dass die Historie unseres master-Branchs von denen der anderen divergiert ist.

Der einzige Weg, die beiden master-Branches zu synchronisieren, besteht darin, sie wieder zusammen zu mergen. Daraus resultieren ein zusätzlicher Merge-Commit und zwei Sets von Commits, die dieselben Änderungen enthalten (die ursprünglichen und die aus dem rebasten Branch). Wir sehen: Die Situation wird unübersichtlich.

Also: Bevor wir git rebase ausführen, sollten wir uns immer fragen, ob sich noch jemand diesen Branch anschaut. Wenn die Antwort Ja ist, sollten wir unbedingt über einen nicht-destruktiven Weg nachdenken, um unsere Änderungen zumachen (z.B. mit git revert).

Pushing erzwingen

Wenn wir versuchen den rebasten master-Branch zurück in ein Remote-Repository zu pushen, wird Git uns davon abhalten, denn es würden Konflikte mit dem Remote-master-Branch entstehen. Allerdings können wir das Pushen mit der Option --force erzwingen:

Damit wird der Remote-master-Branch überschrieben und in Übereinstimmung mit dem rebasten master in unserem Repository gebracht, was die Dinge für den Rest des Teams sehr verwirrend macht. Diesen Befehl sollten wir also mit Vorsicht genießen und ihn nur verwenden, wenn wir wirklich wissen, was wir tun.

Rebasing in den Workflow integrieren

Rebasing können wir so tief (oder weniger tief) in unseren bestehenden Git-Workflow integrieren, wie wir möchten. Durchdenken wir einmal die Vorteile, die Rebasing uns in den diversen Stadien der Feature-Entwicklung bietet.

Der erste Schritt in jedem Workflow, um das Potenzial von git rebase nutzbar zu machen, besteht darin, einen dedizierten Branch für jedes Feature zu erstellen. Das gibt uns die erforderliche Branch-Struktur, um Rebasing sicher anzuwenden:

Lokal aufräumen

Eine der besten Möglichkeiten, um Rebasing in unseren Workflow einzubinden, ist das Aufräumen lokaler Features, die sich in Entwicklung befinden. Indem wir periodisch ein interaktives Rebase durchführen, können wir sicherstellen, dass jeder Commit fokussiert und sinnvoll ist. Somit können wir unseren Code schreiben, ohne uns darum kümmern zu müssen, ihn in isolierte Commits aufzubrechen. Dem können wir uns anschließend widmen.

Wenn wir mit git rebase arbeiten, haben wir zwei Optionen für die neue Base: den Eltern-Branch des Features (z.B. master) oder einen früheren Commit in das Feature. Ein Beispiel für die erste Möglichkeit haben wir im Zusammenhang mit dem interaktiven Rebasing gesehen (siehe den ersten Teil dieser Artikelreihe). Die zweite Option ist gut, wenn wir nur die letzten paar Commits fixen müssen. Die folgenden Befehle leiten ein interaktives Rebasing der letzten drei Commits ein:

git checkout feature
git rebase -i HEAD~3

Indem wir HEAD~3 als neue Base spezifizieren, bewegen wir den Branch nicht tatsächlich – wir schreiben nur die drei Commits interaktiv neu, die folgen. Wir integrieren also keine Upstream-Änderungen in den Feature-Branch.

Rebasing auf HEAD-3

Wenn wir mithilfe dieser Methode das gesamte Feature neu schreiben wollen, kann der Befehle git merge-base sinnvoll sein, um die Original-Base des feature-Branchs zu finden. Das folgende Kommando gibt die Commit-ID der Original-Base aus:

git merge-base feature master

Diese Nutzung des interaktiven Rebasings ist toll, um git rebase in unseren Workflow einzuführen, da es nur lokale Branches betrifft. Andere Entwickler sehen später nur das Endprodukt in Form einer sauberen, einfach nachvollziehbaren feature-Branch-Historie.

Aber nochmals: Das funktioniert nur bei privaten feature-Branches. Wenn wir mit anderen Entwicklern an einem feature-Branch zusammenarbeiten, handelt es sich um einen öffentlichen Branch, und wir dürfen dessen Historie nicht neu schreiben.

git merge kann keine Alternative anbieten, um lokale Commits wie mit einem interaktiven Rebasing aufzuräumen.

Weitere Integrationsmöglichkeiten von git rebase in unseren Entwicklungs-Workflow mit Git behandeln wir im folgenden und abschließenden dritten Artikel zum Thema.

Weiterführende Infos: Ihr Partner für Git und Stash

Kennen Sie Stash, Atlassians Git-Repository-Managementsystem? Stash bietet eine zentrale Lösung zum Management des gesamten distributierten Codes: Hier kommen alle Git-Repositories im Unternehmen zusammen, hier finden Entwickler immer die letzte offizielle Version eines Projekts, hier können Projektverantwortliche Berechtigungen kontrollieren, um sicherzustellen, dass die richtigen Nutzer Zugriff auf den richtigen Code haben.

Möchten Sie mehr erfahren? Wir sind offizieller Vertriebspartner von Atlassian und einer der größten Atlassian Experts Partner weltweit. Gerne unterstützen wir Sie bei der Evaluierung, Lizenzierung und Adaption von Stash. Und wenn Sie Atlassian-Lizenzen bei //SEIBERT/MEDIA kaufen, gewähren wir Ihnen einen Rabatt in Höhe von 10% der Lizenzkosten in Form von Beratungsleistungen. Bitte sprechen Sie uns einfach an.

99 Argumente für Stash als Git-Repository-Manager
Branch-basierte Git-Workflows mit Stash adaptieren
Echte Integration: Das Zusammenspiel von JIRA, Stash und Bamboo
Interview: Die Vorteile von Git in der Software-Entwicklung und die Möglichkeiten von Stash
So funktioniert die Lizenzierung von Atlassian-Produkten