3.2 Git Branching - Einfaches Branching und Merging

Lassen Sie uns zunächst annehmen, Sie arbeiten an Ihrem Projekt und haben bereits ein paar Commits in Ihre master-Branch gemacht.

Sie haben sich dafür entschieden, an „Issue #53“ zu arbeiten aus irgendeinem Fehlerverfolgunssystem, das Ihre Firma benutzt. Um einen neuen Branch anzulegen und gleichzeitig zu diesem zu wechseln, können Sie die Anweisung git checkout zusammen mit der Option -b ausführen:

Das ist die Kurzform der beiden folgenden Befehle:

Sie arbeiten an Ihrer Website und führen einige Commits durch. Sobald Sie das machen, bewegt das den iss53-Branch vorwärts, weil Sie in ihn gewechselt (engl. checked out) haben. Das bedeutet, Ihr HEAD zeigt auf diesen Branch:

Jetzt bekommen Sie einen Anruf, dass es ein Problem mit der Website gibt und Sie es umgehend beheben müssen. Bei Git müssen Sie Ihren Fix nicht zusammen mit den Änderungen bereitstellen, die Sie bereits an iss53 vorgenommen haben, und Sie müssen auch keinen großen Aufwand damit betreiben, diese Änderungen rückgängig zu machen, bevor Sie daran arbeiten können, Ihren Fix auf das anzuwenden, was sich in der Produktionsumgebung befindet. Alles, was Sie machen müssen, ist, zu Ihrem master-Branch zurück zu wechseln.

Beachten Sie dabei, dass Git das Wechseln zu einer anderen Branch blockiert, falls Ihr Arbeitsverzeichnis oder Ihr Staging-Bereich nicht committete Modifikationen enthält, die Konflikte verursachen. Es ist am besten, einen sauberen Zustand des Arbeitsbereichs anzustreben, bevor Sie die Zweige wechseln. Es gibt Möglichkeiten, das zu umgehen (nämlich das Verstecken/Stashen und Revidieren/Amending von Änderungen), die wir später in Kapitel 7 Git Stashing behandeln werden. Lassen Sie uns vorerst annehmen, Sie haben für alle Ihre Änderungen Commits durchgeführt, sodass Sie zu Ihrem master-Branch zurück wechseln können.

Zu diesem Zeitpunkt befindet sich das Arbeitsverzeichnis des Projektes in exakt dem gleichen Zustand, in dem es sich befand, bevor Sie mit der Arbeit an „Issue #53“ begonnen haben und Sie können sich direkt auf den Hotfix konzentrieren. Das ist ein wichtiger Punkt, den Sie unbedingt beachten sollten: Wenn Sie die Branches wechseln, setzt Git Ihr Arbeitsverzeichnis zurück, um so auszusehen, wie es das letzte Mal war, als Sie in den Branch committed haben. Dateien werden automatisch hinzugefügt, entfernt und verändert, um sicherzustellen, dass Ihre Arbeitskopie auf dem selben Stand ist wie zum Zeitpunkt Ihres letzten Commits auf diesem Branch.

Als Nächstes müssen Sie sich um den Hotfix kümmern. Lassen Sie uns einen hotfix-Branch erstellen, an dem Sie bis zu dessen Fertigstellung arbeiten:

Sie können Ihre Tests durchführen, sich vergewissern, dass der Hotfix das macht, was Sie von ihm erwarten und schließlich den Branch hotfix wieder in Ihren master-Zweig integrieren (engl. merge), um ihn in der Produktion einzusetzen. Das machen Sie mit der Anweisung git merge:

Ihnen wird bei diesem Zusammenführen der Ausdruck „fast-forward“ auffallen. Da der Commit C4, auf den der von Ihnen eingebundene Branch hotfix zeigt, direkt vor dem Commit C2 liegt, auf dem Sie sich befinden, bewegt Git den Pointer einfach nach vorne. Um es anders auszudrücken, wenn Sie versuchen, einen Commit mit einem Commit zusammenzuführen, der durch Verfolgen der Historie des ersten Commits erreicht werden kann, vereinfacht Git die Dinge, indem er den Zeiger nach vorne bewegt, da es keine abweichenden Arbeiten gibt, die miteinander gemergt werden müssen – das wird als „fast-forward“ bezeichnet.

Ihre Änderung befindet sich nun im Schnappschuss des Commits, auf den der master-Branch zeigt und Sie können Ihre Fehlerbehebung anwenden.

Nachdem Ihre überaus wichtige Fehlerbehebung bereitgestellt wurde, können Sie sich wieder dem zuwenden, woran Sie gerade gearbeitet haben, als Sie unterbrochen wurden. Zunächst sollten Sie jedoch den hotfix-Branch löschen, weil Sie diesen nicht länger benötigen – schließlich verweist der master-Branch auf den selben Entwicklungsstand. Sie können ihn mit der Anweisung git branch und der Option -d löschen:

Jetzt können Sie zu dem Branch zurückwechseln, auf dem Sie mit Ihren Arbeiten an „Issue #53“ begonnen hatten, und daran weiter arbeiten.

Es ist erwähnenswert, dass die Arbeit, die Sie in Ihrem hotfix-Branch durchgeführt haben, nicht in den Dateien in Ihrem iss53-Branch enthalten ist. Wenn Sie diese Änderungen übernehmen müssen, können Sie in Ihren master-Branch den iss53-Zweig einbinden indem Sie git merge master ausführen, oder Sie können warten, bis Sie sich später entscheiden, den iss53-Zweig wieder zurück nach master zu pullen.

Angenommen, Sie haben entschieden, dass Ihr Issue #53 abgeschlossen ist und Sie bereit sind, ihn in Ihren „Master“ Branch zu integrieren. Dann werden Sie Ihren iss53-Branch in den master-Branch mergen, so wie Sie es zuvor mit dem hotfix-Branch gemacht haben. Sie müssen nur mit der Anweisung checkout zum dem Branch wechseln, in welchen Sie etwas einfließen lassen wollen und dann die Anweisung git merge ausführen:

Das sieht ein bisschen anders aus, als das Merging mit dem hotfix-Branch, das Sie zuvor gemacht haben. Hier hat sich der Entwicklungsverlauf an einem früheren Zustand geteilt. Da der Commit auf dem Branch, auf dem Sie sich gerade befinden, kein unmittelbarer Vorgänger des Branchs ist, in den Sie fusionieren, muss Git einige Arbeiten erledigen. In diesem Fall führt Git einen einfachen Drei-Wege-Merge durch, indem er die beiden Schnappschüsse verwendet, auf die die Branch-Spitzen und der gemeinsame Vorfahr der beiden zeigen.

Anstatt einfach den Zeiger des Branches vorwärts zu bewegen, erstellt Git einen neuen Schnappschuss, der aus dem Drei-Wege-Merge resultiert und erzeugt automatisch einen neuen Commit, der darauf zeigt. Das wird auch als Merge-Commit bezeichnet und ist ein Spezialfall, weil er mehr als nur einen Vorgänger hat.

Da Ihre Änderungen jetzt eingeflossen sind, haben Sie keinen weiteren Bedarf mehr für den iss53-Branch. Sie können den Issue in Ihrem Issue-Tracking-System schließen und den Branch löschen:

Gelegentlich verläuft der Merge-Prozess nicht ganz reibungslos. Wenn Sie in den beiden Branches, die Sie zusammenführen wollen, an der selben Stelle in der selben Datei unterschiedliche Änderungen vorgenommen haben, wird Git nicht in der Lage sein, diese sauber zusammenzuführen. Wenn Ihr Fix für „Issue #53“ den gleichen Teil einer Datei wie der Branch hotfix geändert hat, erhalten Sie einen Merge-Konflikt, der ungefähr so aussieht:

Git konnte automatisch keinen neuen Merge-Commit erstellen. Es hat den Prozess angehalten, bis Sie den Konflikt beseitigt haben. Wenn Sie sehen möchten, welche Dateien nach einem Merge-Konflikt an einem bestimmten Punkt nicht zusammengeführt wurden, können Sie git status ausführen:

Alles, was Merge-Konflikte ausgelöst hat und nicht behoben wurde, wird als unmerged angezeigt. Git fügt den Dateien, die Konflikte haben, Standardmarkierungen zur Konfliktlösung hinzu, so dass Sie sie manuell öffnen und diese Konflikte lösen können. Ihre Datei enthält einen Bereich, der in etwa so aussieht:

Das bedeutet, die Version in HEAD (Ihres master-Branches, denn der wurde per checkout aktiviert, als Sie das merge gestartet haben) ist der obere Teil des Blocks (alles oberhalb von =======) und die Version aus dem iss53-Branch sieht wie der darunter befindliche Teil aus. Um den Konflikt zu lösen, müssen Sie sich entweder für einen der beiden Teile entscheiden oder Sie führen die Inhalte selbst zusammen. Sie können diesen Konflikt beispielsweise lösen, indem Sie den gesamten Block durch diesen ersetzen:

Diese Lösung hat von beiden Teilen etwas und die Zeilen mit <<<<<<<, ======= und >>>>>>> wurden vollständig entfernt. Nachdem Sie alle problematischen Bereiche in allen von dem Konflikt betroffenen Dateien beseitigt haben, führen Sie einfach die Anweisung git add für alle betroffenen Dateien aus, um sie als gelöst zu markieren. Dieses Staging der Dateien markiert sie für Git als bereinigt.

Wenn Sie ein grafisches Tool benutzen möchten, um die Probleme zu lösen, dann können Sie git mergetool verwenden, welches ein passendes grafisches Merge-Tool startet und Sie durch die Konfliktbereiche führt:

Wenn Sie ein anderes Merge-Tool anstelle des Standardwerkzeugs verwenden möchten (Git wählte in diesem Fall opendiff, da die Anweisung auf einem Mac ausgeführt wurde), dann können Sie alle unterstützten Werkzeuge oben – nach „one of the following tools“ – aufgelistet sehen. Tippen Sie einfach den Namen des gewünschten Programms ein.

Nachdem Sie das Merge-Tool beendet haben, werden Sie von Git gefragt, ob das Zusammenführen erfolgreich war. Wenn Sie dem Skript bestätigen, dass es das war, wird die Datei der Staging-Area hinzugefügt und der Konflikt als gelöst zu markiert. Sie können den Befehl git status erneut ausführen, um zu überprüfen, ob alle Konflikte gelöst wurden:

Wenn Sie damit zufrieden sind und Sie geprüft haben, dass alles, was Konflikte aufwies, zum Index hinzugefügt wurde, können Sie die Anweisung git commit ausführen, um den Merge-Commit abzuschließen. Die standardmäßige Commit-Nachricht sieht ungefähr so aus:

Sie können dieser Commit-Nachricht noch Details darüber hinzufügen, wie Sie diesen Merge-Konflikt gelöst haben. Es könnte für künftige Betrachter dieses Commits hilfreich sein zu verstehen, warum Sie was getan haben, falls es nicht offensichtlich ist.