3.2 Git Branching - Einfaches Branching und Merging

Lass uns zunächst annehmen, du arbeitest an deinem Projekt und hast bereits ein paar Commits in deinem master Branch gemacht.

Du hast dich dafür entschieden, an „Issue #53“ aus irgendeinem Fehlerverfolgungssystem, das deine Firma benutzt, zu arbeiten. Um einen neuen Branch anzulegen und gleichzeitig zu diesem zu wechseln, kannst du die Anweisung git checkout zusammen mit der Option -b ausführen:

Das ist die Kurzform der beiden folgenden Befehle:

Du arbeitest an deiner Website und führst einige Commits durch. Sobald du das machst, bewegt das den iss53 Branch vorwärts, weil du in ihn gewechselt (engl. checked out) bist. Das bedeutet, dein HEAD zeigt auf diesen Branch:

Jetzt bekommst du einen Anruf, dass es ein Problem mit der Website gibt und du es umgehend beheben musst. Bei Git musst du deinen Fix nicht zusammen mit den Änderungen bereitstellen, die du bereits an iss53 vorgenommen hast. Du musst auch keinen großen Aufwand betreiben, diese Änderungen rückgängig zu machen, bevor du an den neuen Hotfix arbeiten kannst, um die Produktionsumgebung zu fixen. Alles, was du machen musst, ist zu deinem vorherigen master Branch zu wechseln.

Beachten dabei, dass Git das Wechseln zu einem anderen Branch blockiert, falls dein Arbeitsverzeichnis oder dein Staging-Bereich nicht committete Modifikationen enthält, die Konflikte verursachen. Generell ist es am besten, einen sauberen Zustand des Arbeitsbereichs anzustreben, bevor du Branches wechselst. Es gibt Möglichkeiten, das zu umgehen (nämlich das Verstecken (engl. Stashen) und Revidieren (engl. Amending) von Änderungen), die wir später in Kapitel 7 Git Stashing behandeln werden. Lass uns vorerst annehmen, du hast für alle deine Änderungen Commits durchgeführt, sodass du zu deinem vorherigen master Branch wechseln kannst.

Zu diesem Zeitpunkt befindet sich das Arbeitsverzeichnis des Projektes in exakt dem gleichen Zustand, in dem es sich befand, bevor du mit der Arbeit an „Issue #53“ begonnen hast und du kannst dich direkt auf den Hotfix konzentrieren. Das ist ein wichtiger Punkt, den du unbedingt beachten solltest: Wenn du die Branches wechselst, setzt Git dein Arbeitsverzeichnis zurück, um so auszusehen, wie es das letzte Mal war, als du in den Branch committed hast. Dateien werden automatisch hinzugefügt, entfernt und verändert, um sicherzustellen, dass deine Arbeitskopie auf demselben Stand ist wie zum Zeitpunkt deines letzten Commits auf diesem Branch.

Als Nächstes musst du dich um den Hotfix kümmern. Lass uns einen hotfix Branch erstellen, an dem du bis zu dessen Fertigstellung arbeitest:

Du kannst deine Tests durchführen, dich vergewissern, dass der Hotfix das macht, was du von ihm erwartest und schließlich den Branch hotfix wieder in deinen master Branch integrieren (engl. merge), um ihn in der Produktion einzusetzen. Das machst du mit der Anweisung git merge:

Dir wird bei diesem Zusammenführen der Ausdruck „fast-forward“ auffallen. Da der Commit C4, auf den der von dir eingebundene Branch hotfix zeigt, direkt vor dem Commit C2 liegt, auf dem du dich befindest, bewegt Git den Pointer einfach nach vorne. Um es anders auszudrücken: Wenn du versuchst, 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 verzweigte Arbeiten gibt, die miteinander gemerged werden müssen – das wird als „fast-forward“ bezeichnet.

Deine Änderung befindet sich nun im Schnappschuss des Commits, auf den der master Branch zeigt und du kannst deinen Fix ausliefern und installieren.

Nachdem deine überaus wichtiger Fix bereitgestellt wurde, kannst du dich wieder dem zuwenden, woran du vorher gearbeitet hast. Zunächst solltest du jedoch den hotfix Branch löschen, weil du diesen nicht länger benötigst – schließlich verweist der master Branch auf denselben Entwicklungsstand. Du kannst ihn mit der Anweisung git branch und der Option -d löschen:

Jetzt kannst du zum vorherigen Branch wechseln, auf dem du mit deinen Arbeiten an „Issue #53“ begonnen hattest und daran weiter arbeiten.

Erwähnenswert ist, dass die Änderungen, die du in deinem hotfix Branch durchgeführt hast, nicht in den Dateien deines iss53 Branch enthalten sind. Wenn du diese Änderungen übernehmen willst, kannst du deinen master Branch in den iss53 Branch mergen, indem du git merge master ausführst. Du kannst aber auch warten und dich später dazu entscheiden, den iss53 Branch in master zu übernehmen (engl. pullen).

Angenommen, du hast dich entschieden, dass dein Issue #53 abgeschlossen ist und du bereit bist, ihn in deinem Branch master zu mergen. Dann wirst du deinen iss53 Branch in den master Branch mergen, so wie du es zuvor mit dem hotfix Branch gemacht hast. Du musst nur mit der Anweisung checkout zum Branch wechseln, in welchen du etwas einfließen lassen willst und dann die Anweisung git merge ausführen:

Das sieht ein bisschen anders aus, als das Merging mit dem hotfix Branch, welches du zuvor gemacht hast. Hier hat sich der Entwicklungsverlauf an einem früheren Zustand geteilt. Da der Commit auf dem Branch, auf dem du dich gerade befindest, kein unmittelbarer Vorgänger des Branches ist, in den du mergst, 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 das Branch-Ende und der gemeinsame Vorgänger 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 deine Änderungen jetzt eingeflossen sind, hast du keine weitere Verwendung mehr für den iss53 Branch. Du kannst den Issue in deinem Issue-Tracking-System schließen und den Branch löschen:

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

Git konnte einen neuen Merge-Commit nicht automatisch erstellen. Es hat den Prozess angehalten, bis du den Konflikt beseitigt hast. Wenn du sehen möchtest, welche Dateien zu irgendeinem Zeitpunkt nach einem Merge-Konflikt nicht zusammengeführt wurden, kannst du 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 du sie manuell öffnen und diese Konflikte lösen können. Deine Datei enthält einen Bereich, der in etwa so aussieht:

Das bedeutet, die Version in HEAD (das ist der aktuelle commit master Branches, denn der wurde per checkout aktiviert, als du den Merge gestartet hast) ist der obere Teil des Blocks (alles oberhalb von =======) und die Version aus dem iss53 Branch ist in dem darunter befindliche Teil. Um den Konflikt zu lösen, musst du dich entweder für einen der beiden Teile entscheiden oder du führst die Inhalte selbst zusammen. Du kannst diesen Konflikt beispielsweise lösen, indem du den gesamten Block durch diesen ersetzen:

Diese Lösung hat von beiden Teilen etwas und die Zeilen mit <<<<<<<, ======= und >>>>>>> wurden vollständig entfernt. Nachdem du alle problematischen Bereiche in allen von dem Konflikt betroffenen Dateien beseitigt hast, führst du 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 du ein grafisches Tool benutzen möchtest, um die Probleme zu lösen, dann kannst du git mergetool verwenden, welches ein passendes grafisches Merge-Tool startet und dich durch die Konfliktbereiche führt:

Wenn du 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 kannst du alle unterstützten Werkzeuge sehen, die oben nach „one of the following tools“ aufgelistet sind. Tippe einfach den Namen des gewünschten Programms ein.

Nachdem du das Merge-Tool beendet hast, wirst du von Git gefragt, ob das Zusammenführen erfolgreich war. Wenn du das bestätigst, wird die Datei der Staging-Area hinzugefügt und der Konflikt als gelöst markiert. Du kannst den Befehl git status erneut ausführen, um zu überprüfen, ob alle Konflikte gelöst wurden:

Wenn du damit zufrieden bist und geprüft hast, dass alles, was Konflikte aufwies, der Staging-Area hinzugefügt wurde, kannst du die Anweisung git commit ausführen, um den Merge-Commit abzuschließen. Die standardmäßige Commit-Nachricht sieht ungefähr so aus:

Du kannst diese Commit-Nachricht noch Details darüber hinzufügen, wie du diesen Merge-Konflikt gelöst hast. Es könnte für künftige Betrachter dieses Commits hilfreich sein, zu verstehen, warum du etwas getan hast, falls es nicht offensichtlich ist.