A3.4 Anhang C: Git-Befehle - Verzweigung und Zusammenführung

Der Befehl git branch ist eigentlich ein Werkzeug zur Verwaltung von Zweigen. Er kann die von Ihnen vorhandenen Zweige auflisten, einen neuen Zweig erstellen, Zweige löschen und Zweige umbenennen.

Ein Großteil von Git Branching widmet sich dem Befehl branch und er wird im gesamten Kapitel verwendet. Wir führen ihn zuerst in Erstellen eines neuen Zweigs ein und gehen die meisten seiner anderen Funktionen (Auflisten und Löschen) in Zweigverwaltung durch.

In Tracking-Zweige verwenden wir die Option git branch -u, um einen Tracking-Zweig einzurichten.

Schließlich gehen wir in Git-Referenzen näher darauf ein, was er im Hintergrund tut.

Der Befehl git checkout wird verwendet, um zwischen Zweigen zu wechseln und Inhalte in Ihr Arbeitsverzeichnis zu übertragen.

Wir begegnen dem Befehl zum ersten Mal in Zweige wechseln zusammen mit dem Befehl git branch.

Wir sehen in Tracking-Zweige, wie man ihn mit dem Flag --track verwendet, um Zweige zu verfolgen.

Wir verwenden ihn in Konflikte auschecken mit --conflict=diff3, um Dateikonflikte erneut einzuführen.

In Reset entmystifiziert gehen wir detaillierter auf seine Beziehung zu git reset ein.

Schließlich gehen wir in Der HEAD auf einige Implementierungsdetails ein.

Das Werkzeug git merge wird verwendet, um einen oder mehrere Zweige in den ausgecheckten Zweig zusammenzuführen. Es wird dann den aktuellen Zweig auf das Ergebnis der Zusammenführung vorrücken.

Der Befehl git merge wurde zuerst in Grundlegende Verzweigung eingeführt. Obwohl er an verschiedenen Stellen im Buch verwendet wird, gibt es nur sehr wenige Variationen des Befehls merge – im Allgemeinen nur git merge <branch> mit dem Namen des einzelnen Zweigs, den Sie zusammenführen möchten.

Wie man einen "squashed merge" (bei dem Git die Arbeit zusammenführt, aber so tut, als wäre es nur ein neuer Commit, ohne die Historie des zusammengeführten Zweigs aufzuzeichnen) durchführt, haben wir ganz am Ende von Gabelprojekt behandelt.

In Fortgeschrittene Zusammenführung haben wir viel über den Zusammenführungsprozess und Befehl gelernt, einschließlich des Befehls -Xignore-space-change und des Flags --abort zum Abbrechen einer problematischen Zusammenführung.

In Commits signieren haben wir gelernt, wie man Signaturen vor dem Zusammenführen überprüft, falls Ihr Projekt GPG-Signierung verwendet.

Schließlich haben wir uns in Subtree-Zusammenführung mit der Subtree-Zusammenführung beschäftigt.

Der Befehl git mergetool startet einfach einen externen Merge-Helfer, falls Sie Probleme bei einer Zusammenführung in Git haben.

Wir erwähnen ihn kurz in Grundlegende Zusammenführungskonflikte und gehen im Detail darauf ein, wie Sie Ihren eigenen externen Merge-Tool in Externe Merge- und Diff-Tools implementieren können.

Der Befehl git log wird verwendet, um die erreichbare aufgezeichnete Historie eines Projekts vom neuesten Commit-Snapshot rückwärts anzuzeigen. Standardmäßig zeigt er nur die Historie des aktuell aktiven Zweigs an, kann aber verschiedene oder sogar mehrere Köpfe oder Zweige zum Durchlaufen erhalten. Er wird auch oft verwendet, um Unterschiede zwischen zwei oder mehr Zweigen auf Commit-Ebene anzuzeigen.

Dieser Befehl wird in fast jedem Kapitel des Buches verwendet, um die Historie eines Projekts zu demonstrieren.

Wir führen den Befehl ein und behandeln ihn in einigen Details in Commit-Historie anzeigen. Dort betrachten wir die Optionen -p und --stat, um eine Vorstellung davon zu bekommen, was in jedem Commit eingeführt wurde, und die Optionen --pretty und --oneline, um die Historie übersichtlicher anzuzeigen, zusammen mit einigen einfachen Filteroptionen für Datum und Autor.

In Erstellen eines neuen Zweigs verwenden wir ihn mit der Option --decorate, um einfach zu visualisieren, wo sich unsere Zweigzeiger befinden, und wir verwenden auch die Option --graph, um zu sehen, wie divergierende Historien aussehen.

In Privates kleines Team und Commit-Bereiche behandeln wir die Syntax branchA..branchB, um den Befehl git log zu verwenden, um zu sehen, welche Commits auf einem Zweig im Verhältnis zu einem anderen Zweig eindeutig sind. In Commit-Bereiche gehen wir ziemlich ausführlich darauf ein.

In Merge-Log und Drei-Punkt-Notation behandeln wir die Verwendung des Formats branchA…​branchB und der Syntax --left-right, um zu sehen, was in einem oder dem anderen Zweig, aber nicht in beiden enthalten ist. In Merge-Log schauen wir uns auch an, wie man die Option --merge zur Fehlersuche bei Zusammenführungskonflikten verwendet, sowie die Option --cc, um Zusammenführungskonflikte in Ihrer Historie zu betrachten.

In RefLog-Kurznamen verwenden wir die Option -g, um das Git-Reflog über dieses Werkzeug anzuzeigen, anstatt eine Zweigdurchquerung durchzuführen.

In Suchen untersuchen wir die Verwendung der Optionen -S und -L, um ziemlich ausgefeilte Suchen nach etwas durchzuführen, das historisch im Code passiert ist, wie z. B. die Historie einer Funktion zu sehen.

In Commits signieren sehen wir, wie man --show-signature verwendet, um jeder Commit-Ausgabe von git log eine Validierungszeichenfolge hinzuzufügen, basierend darauf, ob sie gültig signiert wurde oder nicht.

Der Befehl git stash wird verwendet, um nicht committete Arbeit vorübergehend zu speichern, um Ihr Arbeitsverzeichnis zu bereinigen, ohne unvollendete Arbeit in einem Zweig committen zu müssen.

Dies wird im Grunde vollständig in Stashing und Bereinigen behandelt.

Der Befehl git tag wird verwendet, um einen permanenten Lesezeichen für einen bestimmten Punkt in der Codehistorie zu setzen. Im Allgemeinen wird dies für Dinge wie Releases verwendet.

Dieser Befehl wird eingeführt und detailliert in Tagging behandelt und wir verwenden ihn in der Praxis in Ihre Releases taggen.

Wir behandeln auch, wie man mit dem Flag -s einen GPG-signierten Tag erstellt und mit dem Flag -v einen verifiziert, in Ihre Arbeit signieren.