In Git bezieht sich ein Zweig auf die Trennung von der Hauptlinie, um andere Vorgänge auszuführen. Die Hauptlinie kann weiterhin ihre Arbeit erledigen. Sie kann zur Lösung vorübergehender Anforderungen verwendet werden Wenn die Verzweigung abgeschlossen ist, kann sie in die Hauptzeile eingefügt werden. Wenn die Aufgabe der Verzweigung abgeschlossen ist, kann sie gelöscht werden.
Die Betriebsumgebung dieses Tutorials: Windows 7-System, Git-Version 2.30.0, Dell G3-Computer.
Was ist ein Git-Zweig? Wie der Name schon sagt, wird ein Zweig von der Hauptlinie getrennt, um andere Vorgänge auszuführen, ohne dass die Hauptlinie ihre Arbeit fortsetzen kann Ist es ein bisschen wie ein Thread? Der letzte Zweig. Nachdem die Aufgabe abgeschlossen ist, wird sie in die Hauptzeile eingefügt und die Zweigaufgabe ist abgeschlossen und kann gelöscht werden. Ist das nicht sehr praktisch? Die Hauptlinie erledigt weiterhin ihre Aufgabe und die Zweige werden zur Lösung vorübergehender Bedürfnisse verwendet. Die beiden haben nichts miteinander zu tun. Die Verzweigungsfunktion von Git ist besonders leistungsfähig. Sie muss nicht alle Daten kopieren, solange der Zeiger der Verzweigung neu erstellt wird, um auf die Stelle zu zeigen, an der Sie mit der Erstellung der Verzweigung beginnen müssen (Commit). Zeigen Sie auf Ihr letztes Commit-Objekt, und der Zeiger des ursprünglichen Zweigs zeigt auf den Speicherort Ihrer ursprünglichen Entwicklung. Wenn Sie auf welchem Zweig entwickeln, zeigt HEAD auf das neueste Commit-Objekt dieses Zweigs. Es macht nichts, wenn Sie es nicht klar verstehen. Es gibt ein solches Konzept, und Sie werden es später nach und nach verstehen.
Erstellen und Zusammenführen von Zweigen
Mit dem Befehl git branch können wir überprüfen, wie viele Zweige unser Git-Lager hat und an welchem Zweig wir gerade arbeiten. Der mit einem * davor ist, wo wir uns befinden derzeit. Wir können einen Zweig erstellen, indem wir den Namen des Git-Zweigs befehlen. Der Zeiger dieses Zweigs zeigt auf das neueste Commit-Objekt, das auf dasselbe Objekt wie HEAD zeigt. Wir können über den Befehl „git checkout name“ zum Zielzweig wechseln. Unser Standard-Hauptzweig ist „master“. Beim Erstellen und Wechseln von Zweigen ist es eigentlich nur eine einfache Sache, einen Zeiger zu erstellen, um den Zeiger zu finden, dann das Festschreibungsobjekt zu finden, auf das der gefundene Zeiger zeigt, und dann den Arbeitsbereich in dem Datei-Snapshot wiederherzustellen, auf den das Festschreibungsobjekt zeigt damit wir arbeiten können. Bei einmaliger Übermittlung zeigt der Zeiger wieder auf das zuletzt übermittelte Objekt, was sehr einfach ist.
Bevor wir den Zweig teset eingerichtet haben, gab es nur einen Hauptzweig, wie in Abbildung 1 dargestellt. Unsere gesamte Entwicklung befand sich in diesem Zweig, und HEAD zeigte auf das zuletzt übermittelte Festschreibungsobjekt c3. Es gab auch c3 Vor dem zweimaligen Senden von c1 und c2 erstellen wir den Testzweig über den Git-Zweigtest, wie in Abbildung 2 dargestellt. Zu diesem Zeitpunkt zeigt HEAD immer noch auf den zuletzt vom Master-Zweig übermittelten Zweig Im Testzweig zeigt HEAD auf den Testzweig. Die aktuellste Übermittlung von c3 verweist tatsächlich auf die gleichen Daten wie c3 in .git.
Zu diesem Zeitpunkt, wenn wir den Testzweig mehrmals entwickelt und die beiden Versionen c4 und c5 eingereicht haben, verweisen sowohl Test als auch HEAD auf die neueste Übermittlung c5 des Testzweigs, wie in Abbildung 3 dargestellt. und master this Es gibt noch keine Änderung und es zeigt immer noch auf c3. Wenn der Testzweig zu diesem Zeitpunkt mit dem Master-Zweig zusammengeführt wird, muss Git überhaupt nichts tun. Er muss nur den Master auf den Punkt verschieben bis c5. Dieser Vorgang wird Fast-Forward-Enter genannt. Wenn die Testaufgabe zu diesem Zeitpunkt abgeschlossen ist, können wir sie über git branch -d test löschen und die Entwicklung auf dem Hauptzweigmaster fortsetzen. Wenn dies der Fall ist, wird der Testzweig vergeblich erstellt.
Wenn also zu diesem Zeitpunkt eine weitere Entwicklung im Master-Zweig durchgeführt wird und zwei Versionen c6 und c7 übermittelt werden, dann zeigen die Master- und HEAD-Zeiger zu diesem Zeitpunkt auf c7, wie in Abbildung 4 dargestellt which Wenn Sie auf einem Zweig entwickeln, zeigt HEAD auf den Commit, auf dem Sie die beiden Zweige zu diesem Zeitpunkt zusammenführen.
Wie in Abbildung 5 gezeigt, wechseln wir zuerst zum Master-Zweig und führen dann den Testzweig über Git Merge Test mit dem Master-Zweig zusammen. Zu diesem Zeitpunkt bewegt Git nicht mehr einfach den Zeiger, da auf beiden Seiten eine Entwicklung stattfindet , also muss sich Git mit beiden befassen. Die neuesten Commits c5 und c7 der Zweige und das gemeinsame Vorfahren-Commit-Objekt c3 der beiden Zweige werden verwendet, um eine einfache Drei-Parteien-Zusammenführung durchzuführen, die einen neuen Datei-Snapshot generiert und ihn mit aufzeichnet Neues Commit-Objekt c8. Sie müssen diesem Zusammenführungsprozess nicht allzu viel Aufmerksamkeit schenken. Wenn ein Konflikt auftritt, dh zwei Zweige haben dieselbe Datei geändert, stoppt Git den Zusammenführungsvorgang Behandeln Sie den Konflikt, senden Sie ihn dann (c8) und führen Sie ihn dann zusammen. Zu diesem Zeitpunkt verweisen sowohl Master als auch HEAD auf c8, aber Test wurde nicht verschoben. Zu diesem Zeitpunkt können Sie Test weiter entwickeln und ihn dann in Master zusammenführen .
Lokaler Zweig, Tracking-Zweig und Remote-Zweig
Hier gibt es drei Konzepte: Der lokale Zweig ist der Zweig, den wir über den Git-Zweig anzeigen können, das heißt, der Zweig, der unserem eigenen Git-Lager gehört, können wir alle Benutze es. Der Remote-Zweig ist ein Index der Zweige des Remote-Warehouse. Es handelt sich tatsächlich um einen lokalen Zweig, den wir jedoch nicht verschieben können. Wir müssen mit dem zentralen Server interagieren und ihn entsprechend dem vom Server aktualisierten Code verschieben Der Remote-Zweig ist der, mit dem wir zuletzt interagiert haben. Die neueste Version, die durch das interaktive Update des zentralen Servers erhalten wurde, ist ebenfalls ein Zeiger. Der Tracking-Zweig ist schwieriger zu verstehen, aber er entspricht einem Remote-Zweig. Wenn einer unserer lokalen Zweige einem bestimmten Remote-Zweig entspricht, handelt es sich beispielsweise um unseren ursprünglichen Master-Zweig ist ein Tracking-Zweig, der dem Remote-Zweig „Origin/Master“ entspricht, wobei „Origin“ der Name des Remote-Warehouse ist, wenn wir Aktualisierungen (Fetch, Pull) oder Push (Push) im Master-Zweig durchführen, ohne einen Zweig anzugeben , der Standardwert ist origin/ Der Master-Zweig wird aktualisiert oder an den origin/mster-Zweig übermittelt.
Aus Abbildung 7 und Abbildung 8 ist leicht zu erkennen, dass es der Erstellung unseres lokalen Zweigs sehr ähnlich ist, mit der Ausnahme, dass der Ursprungs-/Master-Remote-Zweig erst verschoben wird, nachdem eine Verbindung zum Server hergestellt und der Server aktualisiert wurde Code lokal, wie in Abbildung 9 unten dargestellt:
Es gibt zwei Befehle zum Aktualisieren des Remote-Codes auf den lokalen Code: Fetch und Pull aktualisieren den Remote-Code auf den lokalen Code, führen jedoch keinen Zusammenführungsvorgang aus Sie müssen es selbst überprüfen, Konflikte lösen usw. und es dann selbst ausführen. Merge führt den aktualisierten Code in unserem eigenen Zweig zusammen, aber Pull kombiniert diese beiden Vorgänge in einem Schritt und aktualisiert den Servercode direkt Wenn Sie auf Konflikte stoßen, müssen Sie diese selbstverständlich selbst lösen. Daher verwenden wir im Allgemeinen Fetch zum Implementieren von Updates. Dies ist zwar etwas mühsam, aber nicht anfällig für Probleme.
Übertragen Sie den lokalen Code an das Remote-Warehouse, d. Die Daten unserer lokalen Hauptniederlassung werden an die Hauptniederlassung des Remote-Warehouse-Ursprungs gesendet. Wenn der lokale Master-Zweig ein Tracking-Zweig ist, findet er den entsprechenden Zweig im Remote-Warehouse, um die Daten zu übertragen, sofern nicht anders angegeben. Oder wir führen den Git-Push-Ursprungsvorgang direkt aus und geben nur den Namen des Remote-Warehouses an. Dann pusht Git die Daten basierend auf dem Zweig, in dem wir uns gerade befinden, und dem Zweig des entsprechenden Remote-Warehouses, vorausgesetzt, der Zweig, in dem wir uns gerade befinden, muss vorhanden sein ein Tracking-Zweig. Wenn es sich um Git Push Origin: Master handelt, ist der Name des lokalen Zweigs hier natürlich leer. Bei diesem Vorgang wird der leere Zweig in den Master-Zweig des Remote-Warehouse verschoben, und das Ergebnis ist das Löschen des Master-Zweigs.
Da Tracking-Zweige so einfach zu verwenden sind, gibt es zwei Möglichkeiten: Die erste Möglichkeit besteht darin, Remote-Zweige zu löschen und den Namen des Tracking-Zweigs nicht anzugeben ist der Zweigname des Remote-Warehouses: git checkout --track origin/test, also erstellen wir einen Tracking-Zweig mit dem Namen test. Wenn Sie den Tracking-Zweig umbenennen: git checkout -b name origin/test, also erstellen wir einen Tracking-Zweig Zweig mit dem Namen „Name“ Der Tracking-Zweig entspricht dem Testzweig des Remote-Warehouse. Die zweite Methode besteht darin, dass bereits ein lokaler Zweig vorhanden ist und dieser einem Remote-Zweig entsprechen soll, um zu einem Tracking-Zweig zu werden. Es gibt auch zwei Befehle, die Sie verwenden können: git branch --set-upstream test origin/test oder git branch -f - -track test origin/test Hier lassen wir unseren lokal vorhandenen Testzweig den Remote-Testzweig verfolgen.
git Filialleitung
Mit Git können Zweige so einfach und schnell erstellt und zusammengeführt werden, dass wir während unseres Entwicklungsprozesses beliebig viele Zweige verwenden können. Eines der Kernfunktionen von Git ist das Verzweigen. Die Verwendung von Zweigen wird dringend empfohlen, aber können wir Zweige verwenden? Skrupellos? Wie schaffen wir es, so viele Filialen zu schaffen? Es geht nicht um zu viele Filialen, sondern um die richtige Menge. Flow und empfehlen Sie auch einen Artikel, um mehr über diese Strategie zu erfahren: http://nvie.com/posts/a-successful-git-branching-model/, um die Verwendung von Git komfortabler zu gestalten.
Empfohlenes Lernen: „Git Tutorial“
Das obige ist der detaillierte Inhalt vonWas bedeutet Zweig in Git?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
