3.2 Git Branching - Grundlegendes Branching und Merging

Zunächst sagen wir, dass Sie an Ihrem Projekt arbeiten und bereits ein paar Commits auf dem master-Branch haben.

Sie haben beschlossen, an Issue #53 in welchem Issue-Tracking-System Ihr Unternehmen auch immer verwendet, zu arbeiten. Um einen neuen Branch zu erstellen und gleichzeitig zu ihm zu wechseln, können Sie den Befehl git checkout mit dem Schalter -b ausführen.

Dies ist eine Kurzform für

Sie arbeiten an Ihrer Website und machen ein paar Commits. Dadurch bewegt sich der iss53-Branch vorwärts, da Sie ihn ausgecheckt haben (d.h. Ihr HEAD zeigt darauf).

Jetzt erhalten Sie den Anruf, dass es ein Problem mit der Website gibt und Sie es sofort beheben müssen. Mit Git müssen Sie Ihren Fix nicht zusammen mit den Änderungen für iss53 deployen, und Sie müssen nicht viel Aufwand betreiben, um diese Änderungen zurückzusetzen, bevor Sie Ihren Fix auf das, was in der Produktion ist, anwenden können. Alles, was Sie tun müssen, ist, zu Ihrem master-Branch zurückzuwechseln.

Beachten Sie jedoch, dass Git Sie nicht zu einem anderen Branch wechseln lässt, wenn Ihr Arbeitsverzeichnis oder Ihr Staging-Bereich nicht committete Änderungen enthält, die mit dem auszucheckenden Branch in Konflikt stehen. Es ist am besten, einen sauberen Arbeitszustand zu haben, wenn Sie zwischen Branches wechseln. Es gibt Wege, dies zu umgehen (nämlich Stashing und Commit Amending), die wir später in Stashing und Bereinigen behandeln werden. Vorerst gehen wir davon aus, dass Sie alle Ihre Änderungen committet haben, sodass Sie zu Ihrem master-Branch zurückwechseln können.

An diesem Punkt ist Ihr Projektarbeitsverzeichnis genau so, wie es vor Beginn der Arbeit an Issue #53 war, und Sie können sich auf Ihren Hotfix konzentrieren. Dies ist ein wichtiger Punkt, den Sie sich merken sollten: Wenn Sie zu einem anderen Branch wechseln, setzt Git Ihr Arbeitsverzeichnis zurück, damit es so aussieht wie beim letzten Commit auf diesem Branch. Es fügt Dateien hinzu, entfernt sie und modifiziert sie automatisch, um sicherzustellen, dass Ihre Arbeitskopie dem Zustand des Branches bei Ihrem letzten Commit entspricht.

Als Nächstes müssen Sie einen Hotfix durchführen. Lassen Sie uns einen hotfix-Branch erstellen, an dem wir arbeiten, bis er abgeschlossen ist.

Sie können Ihre Tests ausführen, sicherstellen, dass der Hotfix das ist, was Sie wollen, und schließlich den hotfix-Branch zurück in Ihren master-Branch mergen, um ihn in die Produktion zu deployen. Dies tun Sie mit dem Befehl git merge.

Sie werden in diesem Merge die Phrase "fast-forward" bemerken. Da der Commit C4, auf den der Branch hotfix, den Sie gemergt haben, gezeigt hat, direkt vor dem Commit C2 lag, auf dem Sie sich befinden, verschiebt Git den Zeiger einfach nach vorne. Anders ausgedrückt: Wenn Sie versuchen, einen Commit mit einem Commit zu mergen, der durch Verfolgen der Historie des ersten Commits erreicht werden kann, vereinfacht Git die Dinge, indem es den Zeiger nach vorne bewegt, da keine divergierenden Arbeiten zusammengeführt werden müssen – dies wird als "Fast-Forward" bezeichnet.

Ihre Änderung befindet sich nun im Snapshot des Commits, auf den der master-Branch zeigt, und Sie können den Fix deployen.

Nachdem Ihr wichtiger Fix deployed wurde, sind Sie bereit, zu der Arbeit zurückzukehren, die Sie vor Ihrer Unterbrechung geleistet haben. Zuerst löschen Sie jedoch den hotfix-Branch, da Sie ihn nicht mehr benötigen – der master-Branch zeigt auf dieselbe Stelle. Sie können ihn mit der Option -d zu git branch löschen.

Nun können Sie zu Ihrem Branch mit der laufenden Arbeit an Issue #53 zurückwechseln und daran weiterarbeiten.

Es ist erwähnenswert, dass die Arbeit, die Sie in Ihrem hotfix-Branch geleistet haben, nicht in den Dateien Ihres iss53-Branches enthalten ist. Wenn Sie sie übernehmen müssen, können Sie Ihren master-Branch in Ihren iss53-Branch mergen, indem Sie git merge master ausführen, oder Sie können warten, bis Sie diese Änderungen integrieren, bis Sie beschließen, den iss53-Branch später wieder in master zu mergen.

Angenommen, Sie haben beschlossen, dass Ihre Arbeit an Issue #53 abgeschlossen ist und bereit ist, in Ihren master-Branch gemergt zu werden. Um dies zu tun, werden Sie Ihren iss53-Branch in master mergen, ähnlich wie Sie Ihren hotfix-Branch zuvor gemergt haben. Alles, was Sie tun müssen, ist, den Branch auszuchecken, in den Sie mergen möchten, und dann den Befehl git merge auszuführen.

Dies sieht etwas anders aus als der hotfix-Merge, den Sie zuvor durchgeführt haben. In diesem Fall ist Ihre Entwicklungshistorie von einem älteren Punkt abgewichen. Da der Commit auf dem Branch, den Sie gerade auschecken, kein direkter Vorgänger des Branches ist, den Sie mergen, muss Git einige Arbeit leisten. In diesem Fall führt Git einen einfachen Drei-Wege-Merge durch, wobei die beiden Snapshots, auf die die Branch-Spitzen zeigen, und der gemeinsame Vorfahre der beiden verwendet werden.

Anstatt nur den Branch-Zeiger nach vorne zu bewegen, erstellt Git einen neuen Snapshot, der aus diesem Drei-Wege-Merge resultiert, und erstellt automatisch einen neuen Commit, der darauf zeigt. Dies wird als Merge-Commit bezeichnet und ist besonders, da er mehr als einen Elternteil hat.

Nachdem Ihre Arbeit gemergt wurde, benötigen Sie den iss53-Branch nicht mehr. Sie können das Issue in Ihrem Issue-Tracking-System schließen und den Branch löschen.

Gelegentlich verläuft dieser Prozess nicht reibungslos. Wenn Sie denselben Teil derselben Datei in den beiden zu mergenden Branches unterschiedlich geändert haben, kann Git sie nicht sauber mergen. Wenn Ihre Korrektur für Issue #53 denselben Teil einer Datei wie der hotfix-Branch modifiziert hat, erhalten Sie einen Merge-Konflikt, der in etwa wie folgt aussieht:

Git hat keinen neuen Merge-Commit automatisch erstellt. Es hat den Prozess pausiert, während Sie den Konflikt lösen. Wenn Sie zu irgendeinem Zeitpunkt nach einem Merge-Konflikt sehen möchten, welche Dateien nicht gemergt sind, können Sie git status ausführen.

Alles, was Merge-Konflikte aufweist und noch nicht gelöst ist, wird als "nicht gemergt" aufgeführt. Git fügt den Dateien mit Konflikten Standard-Konfliktlösungsmarkierungen hinzu, sodass Sie sie manuell öffnen und die Konflikte lösen können. Ihre Datei enthält einen Abschnitt, der in etwa wie folgt aussieht:

Dies bedeutet, dass die Version in HEAD (Ihr master-Branch, da dies das war, was Sie ausgecheckt hatten, als Sie Ihren Merge-Befehl ausgeführt haben) der obere Teil dieses Blocks ist (alles oberhalb von =======), während die Version in Ihrem iss53-Branch alles in der unteren Hälfte ist. Um den Konflikt zu lösen, müssen Sie entweder die eine oder die andere Seite wählen oder den Inhalt selbst mergen. Sie könnten diesen Konflikt beispielsweise lösen, indem Sie den gesamten Block durch Folgendes ersetzen:

Diese Lösung enthält einen Teil von jeder Sektion, und die Zeilen <<<<<<<, ======= und >>>>>>> wurden vollständig entfernt. Nachdem Sie jeden dieser Abschnitte in jeder konfliktreichen Datei gelöst haben, führen Sie git add für jede Datei aus, um sie als gelöst zu markieren. Das Staging der Datei markiert sie in Git als gelöst.

Wenn Sie ein grafisches Tool verwenden möchten, um diese Probleme zu lösen, können Sie git mergetool ausführen, das ein geeignetes visuelles Merge-Tool startet und Sie durch die Konflikte führt.

Wenn Sie ein anderes Merge-Tool als das Standardtool verwenden möchten (Git hat in diesem Fall opendiff gewählt, da der Befehl unter macOS ausgeführt wurde), können Sie alle unterstützten Tools oben nach "one of the following tools" sehen. Geben Sie einfach den Namen des Tools ein, das Sie bevorzugen.

Nachdem Sie das Merge-Tool beendet haben, fragt Git, ob der Merge erfolgreich war. Wenn Sie dem Skript mitteilen, dass er erfolgreich war, staged es die Datei, um sie für Sie als gelöst zu markieren. Sie können git status erneut ausführen, um zu überprüfen, ob alle Konflikte gelöst wurden.

Wenn Sie damit zufrieden sind und überprüft haben, dass alles mit Konflikten staged wurde, können Sie git commit eingeben, um den Merge-Commit zu finalisieren. Die Commit-Nachricht sieht standardmäßig etwa so aus:

Wenn Sie denken, dass es für andere, die diesen Merge in Zukunft betrachten, hilfreich wäre, können Sie diese Commit-Nachricht mit Details darüber ändern, wie Sie den Merge gelöst haben, und erklären, warum Sie die von Ihnen vorgenommenen Änderungen vorgenommen haben, falls diese nicht offensichtlich sind.