Um es kurz zu machen…

Soweit ich das beurteilen kann, kann sich der Begriff “Zweig” (im Git-Jargon) auf verwandte, aber unterschiedliche Dinge beziehen:

1. eine nicht-symbolische Referenz/Zeiger auf ein Commit,
2. der Name einer solchen Referenz (z. B. “Master”),
3. der Teilgraph des Commit-DAG des Repositorys, der aus allen Commits besteht, die von dem Commit aus erreichbar sind, auf das durch eine solche Referenz verwiesen wird.

Ich habe jedoch gesehen, dass sich der Begriff anscheinend auf etwas anderes als diese drei möglichen Verwendungen bezieht (weitere Details unten). Gibt es in einem Git-Kontext andere gültige und eindeutige Verwendungen des Begriffs „Zweig“, die in meiner obigen Liste fehlen?

Mehr Details

Nachdem ich Git etwa ein Jahr lang verwendet habe, bereite ich ein kurzes Tutorial für CS-Studenten vor. Ich möchte wirklich die Git-Terminologie festnageln, um Verwirrung zu vermeiden.

Natürlich verwende ich seit einiger Zeit Git-Zweige; Ich kann sie gut verwenden und finde das Git-Branching-Modell großartig. Allerdings finde ich den Begriff “Branch” immer noch problematisch und zweideutig, weil er sich auf mindestens zwei verschiedene Dinge zu beziehen scheint, je nachdem, in welchem ​​Kontext er verwendet wird … manchmal sogar in demselben Tutorial/Handbuch.

Verwendung 1: Verzweigung = Zeiger/Referenz auf ein Commit

Das Pro Git-Buch (in 3.1 – Was ein Zweig ist), nachdem das folgende Diagramm gezeigt wurde,

fährt fort, einen Zweig zu definieren als

einfach ein leichter beweglicher Zeiger auf einen dieser Commits.

Soweit ich das beurteilen kann, hat dies auch die Bedeutung von “Branch” in den Git-Manpages.

Ich fühle mich mit dieser Definition vollkommen wohl. Ich stelle mir eine Verzweigung nur als eine Referenz vor, die auf einen bestimmten Commit im DAG zeigt, und das „Tipp-Commit“ einer Verzweigung ist das Commit, auf das diese Referenz zeigt. So weit, ist es gut. Aber warte…

Verwendung 2: Verzweigung = ein Untergraph des DAG

Die Atlassian-Git-Tutorial führt Verzweigungen wie folgt ein:

Ein Zweig stellt eine eigenständige Entwicklungslinie dar.

Was sie damit meinen, denke ich, ist eine Reihe von Commits. Lassen Sie mich diesen Gedanken verfeinern … Die einzige für mich sinnvolle Interpretation ist, dass sich der Begriff “Zweig” auch auf die beziehen kann Subgraph des Commit-DAG des Repositorys, der sich aus allen Commits zusammensetzt, die vom betrachteten Tip-Commit aus erreichbar sind.

Das Pro Git-Buch enthält jedoch beispielsweise auch das folgende Diagramm (siehe 3.4 – Verzweigungsworkflows),

was meiner Interpretation zu widersprechen scheint, weil es zu implizieren scheint, dass nur begangen wird C2–C5 (nicht C1) Gehören zur develop Zweig, und das nur festschreibt C6–C7 (nicht C1–C5) Gehören zur topic sich verzeigen.

Ich finde diese Verwendung zweideutig und vage, denn wenn ich den DAG zu diesem Zeitpunkt zeichnen würde, ohne zu wissen, wohin die Zweigreferenzen in der Vergangenheit gezeigt haben, und ohne die Annahme einer Hierarchie zwischen den drei Zweigen, würde ich nur Folgendes erhalten

Ich finde auch einige Diagramme in anderen Git-Lernressourcen verwirrend. Betrachten Sie insbesondere das folgende (aus dem Einführungsvideo der Lynda.com – Grundlegende Git-Schulung):

Hier die Spitze von master ist eigentlich 534de (und HEAD verweist auf master), aber die Position der “Master”-Beschriftung im Diagramm ist sehr irreführend. Was dieses Etikett in diesem Fall beschreiben soll, ist mir unklar …

Bearbeiten: Ich habe das inzwischen gefunden ausgezeichneter Beitrag auf Marcs Blog; der Geäst Abschnitt wiederholt meine Bemerkungen oben.

Du hast Recht.

Wir können Ihr Element 1 weiter aufteilen, indem wir „lokale“ und „entfernte“ Zweigbezeichnungen trennen: lokale Zweige (lokale Bezeichnungen) sind Namen, die (intern – viele Frontend-Befehle verstecken dies) mit beginnen refs/heads/während „Remote-Zweige“ – die auch als „Remote-Tracking-Zweige“ bezeichnet werden – mit beginnen refs/remotes/ und dann eine weitere Pfadkomponente haben, die die spezifische Fernbedienung vor dem Teil benennt, der den Zweig benennt. (Bearbeitung, April 2018: Ich mag den Ausdruck „Remote-Zweig“ oder „Remote-Tracking-Zweig“ nicht; Ich denke, es ist besser, diese einfach anzurufen Remote-Tracking-Namen. Aber es gibt eine Menge vorhandener Dokumentation, die die anderen beiden Ausdrücke verwendet, also müssen wir uns dieser Verwendung bewusst sein.)

Zum Beispiel sind Sie zweifellos vertraut mit refs/remotes/origin/masteraber wenn Sie eine Fernbedienung mit dem Namen haben bob hast du vielleicht auch refs/remotes/bob/hacks/feep das Bobs verfolgt hacks/feep.

Ein lokaler Zweigname refs/heads/branch hat das Unterscheidungsmerkmal, dass git checkout bringt Sie standardmäßig auf diesen Zweig, indem Sie diesen Namen in das Special schreiben HEAD Hinweis; und sobald Sie auf diese Weise eingerichtet sind, werden neue Commits (erstellt von git commit, git merge, git cherry-pick, etc.) bewirken, dass der SHA-1 des neuen Commits in die Branch-Datei geschrieben wird. (Das neue Commit hat als übergeordnetes Element oder eines seiner übergeordneten Elemente den alten tip-of-branch.)

Ich habe versucht, Begriffe wie „Zweigspitze“ zu verwenden, um speziell das Commit zu bezeichnen, dem ein Zweigname wie folgt refs/heads/master Punkte, “Zweigname” oder “lokaler Zweigname”, um auf den Namen selbst zu verweisen (egal ob mit Präfix refs/heads/ oder nicht) und – ich denke, das ist am wenigsten erfolgreich – „Zweigstruktur“, um sich auf die DAG-Untermenge zu beziehen. Bei einem DAG mit einem Fork-and-Merge wie folgt:

         o--o
        /    \
...-o--o      o--o-...
        \    /
         o--o

Manchmal möchte ich die eine oder andere Hälfte des kleinen Benzolring-ähnlichen Objekts auch als “Ast” bezeichnen, und ich habe keinen wirklich guten Begriff dafür.

(Übrigens, wenn Sie Topologe wären, würde Sie die Tatsache nicht stören, dass das Atlassian-Diagramm auch linear gezeichnet werden kann. Allerdings versuchen Topologen, wie der alte Witz sagt, seit jedem aus ihren Donuts zu trinken und ihre Kaffeetassen zu essen ist nur ein Torus.)

Im zweiten Fall meinen wir “die Commits, die sind erreichbar aus dem Commit, auf das die Verzweigung zeigt”.

Im Pro Git-Beispiel, unter der Annahme, dass die topic Verzweigungspunkte zum Festschreiben C7dieser Zweig enthält Commits C7, C6, C5, C4, C3, C2und C1. Es gibt keine andere Vorstellung davon, dass sich ein Commit „auf“ einem Zweig befindet, als dies in Git, und Sie haben Recht, dass Sie den DAG linear neu zeichnen könnten.

Das Lynda.com-Diagramm ist schrecklich unklar, und ich vermute, Sie haben Recht, dass es irreführend ist.