Ausführliche Erklärung mit Bildern und Text! Verstehen Sie, wie Git funktioniert

Dieser Artikel vermittelt Ihnen relevantes Wissen über das Funktionsprinzip von Git, das hauptsächlich zur detaillierten Erläuterung mit Bildern und Texten verwendet wird. Ich hoffe, dass es für alle hilfreich ist.

Veranschaulichung, wie Git funktioniert

Dieser Artikel veranschaulicht die am häufigsten verwendeten Befehle in Git. Wenn Sie ein wenig über die Funktionsweise von Git Bescheid wissen, kann Ihnen dieser Artikel ein tieferes Verständnis vermitteln.

Die vier oben genannten Befehle kopieren Dateien zwischen dem Arbeitsverzeichnis, dem Staging-Verzeichnis (auch Index genannt) und dem Warehouse.

• git add files fügt die aktuelle Datei in den Staging-Bereich ein.

• git commit generiert einen Snapshot des Staging-Bereichs und übermittelt ihn.

• Git Reset – Dateien wird verwendet, um die letzten Git-Hinzufügungsdateien rückgängig zu machen. Sie können Git Reset auch verwenden, um alle Staging-Bereichsdateien rückgängig zu machen.

• git checkout – files kopiert Dateien aus dem Staging-Bereich in das Arbeitsverzeichnis, um lokale Änderungen zu verwerfen.

Sie können git reset -p, git checkout -p oder git add -p verwenden, um in den interaktiven Modus zu wechseln.

Sie können den Staging-Bereich auch überspringen und Dateien direkt aus dem Lager abrufen oder den Code direkt übermitteln.

• git commit -a entspricht dem Ausführen von git add, um alle Dateien im aktuellen Verzeichnis zum Staging-Bereich hinzuzufügen und es dann auszuführen.

• git commit files führt einen Commit durch, der den letzten Commit sowie einen Snapshot der Dateien im Arbeitsverzeichnis enthält. Und die Datei wird zum Staging-Bereich hinzugefügt.

• git checkout HEAD – Datei-Rollback, um den letzten Commit zu kopieren.

Die Bilder werden in folgender Form im folgenden Artikel verwendet.

Die grünen 5-stelligen Zeichen stellen die übermittelte ID dar, die jeweils auf den übergeordneten Knoten verweist. Zweige werden orange angezeigt und verweisen auf bestimmte Commits. Der aktuelle Zweig wird durch den daran angehängten HEAD identifiziert. Dieses Bild zeigt die letzten 5 Einreichungen, ed489 ist die neueste Einreichung. Der Master-Zweig zeigt auf diesen Commit, und der andere Maint-Zweig zeigt auf den Großeltern-Commit-Knoten.

Diff

Es gibt viele Möglichkeiten, die Änderungen zwischen Commits anzuzeigen, hier sind einige Beispiele.

Commit

Beim Absenden erstellt Git eine neue Übermittlung unter Verwendung der Dateien im Staging-Bereich und legt den Knoten zu diesem Zeitpunkt als übergeordneten Knoten fest. Zeigen Sie dann mit dem aktuellen Zweig auf den neuen Commit-Knoten. Im Bild unten ist der aktuelle Zweig Master. Bevor der Befehl ausgeführt wird, zeigt der Master auf ed489. Nach der Übermittlung zeigt der Master auf den neuen Knoten f0cec mit ed489 als übergeordnetem Knoten.

Selbst wenn der aktuelle Zweig der übergeordnete Knoten einer bestimmten Einreichung ist, funktioniert Git auf die gleiche Weise. In der folgenden Abbildung wird ein Commit für den Maint-Zweig, den Großvaterknoten des Master-Zweigs, durchgeführt und 1800b generiert. Auf diese Weise ist der Hauptzweig nicht mehr der übergeordnete Zweig des Hauptzweigs. Zu diesem Zeitpunkt ist eine Zusammenführung von [1] (oder eine Neubasierung von [2]) erforderlich.

Wenn Sie ein Commit ändern möchten, verwenden Sie git commit –amend. Git führt einen neuen Commit mit demselben übergeordneten Knoten wie der aktuelle Commit durch und der alte Commit wird abgebrochen.

Ein weiteres Beispiel ist die Trennung der HEAD-Einreichung [3], die später besprochen wird.

Checkout

Der Checkout-Befehl wird verwendet, um Dateien aus historischen Übermittlungen (oder dem Staging-Bereich) in das Arbeitsverzeichnis zu kopieren und kann auch zum Wechseln von Zweigen verwendet werden.

Wenn ein Dateiname angegeben wird (oder die Option -p aktiviert ist oder der Dateiname und die Option -p gleichzeitig aktiviert sind), kopiert Git die Datei aus dem angegebenen Commit in den Staging-Bereich und funktioniert Verzeichnis. Beispielsweise kopiert git checkout HEAD~ foo.c foo.c im Übermittlungsknoten HEAD~ (d. h. den übergeordneten Knoten des aktuellen Übermittlungsknotens) in das Arbeitsverzeichnis und fügt es dem Staging-Bereich hinzu. (Wenn im Befehl kein Commit-Knoten angegeben ist, wird der Inhalt aus dem Staging-Bereich kopiert.) Beachten Sie, dass sich der aktuelle Zweig nicht ändert.

Wenn der Dateiname nicht angegeben ist, aber ein (lokaler) Zweig angegeben ist, wird die HEAD-Identifikation in diesen Zweig verschoben (das heißt, wir „wechseln“ zu diesem Zweig) und dann den Staging-Bereich und das Arbeitsverzeichnis wird Der Inhalt stimmt mit dem Übermittlungsknoten überein, der HEAD entspricht. Alle Dateien im neuen Übermittlungsknoten (a47c3 in der Abbildung unten) werden kopiert (in den Staging-Bereich und das Arbeitsverzeichnis); Dateien, die nur im alten Übermittlungsknoten (ed489) vorhanden sind, werden gelöscht; Die beiden oben genannten Dateien werden ignoriert und sind nicht betroffen.

Wenn weder ein Dateiname noch ein Zweigname angegeben wird, sondern ein Label, ein Remote-Zweig, ein SHA-1-Wert oder etwas Ähnliches wie „master~3“, erhalten Sie einen anonymen Zweig mit der Bezeichnung „Detached HEAD“ (Detached HEAD Identifier). . Dies erleichtert den Wechsel zwischen historischen Versionen. Wenn Sie beispielsweise Version 1.6.6.1 von Git kompilieren möchten, können Sie git checkout v1.6.6.1 ausführen (dies ist eine Bezeichnung, kein Zweigname), kompilieren, installieren und dann zu einem anderen Zweig zurückwechseln, z als Git-Checkout-Master. Wenn jedoch ein Commit-Vorgang einen „abgetrennten HEAD“ beinhaltet, ist das Verhalten etwas anders, wie unten beschrieben.

Folgen Sie dem öffentlichen Konto „Java Backend Technology Full Stack“, antworten Sie auf das Interview und erhalten Sie hochwertige Interviewinformationen

Senden Sie den Vorgang, wenn sich die HEAD-Kennung in einem getrennten Zustand befindet.

Wenn sich HEAD in befindet In einem getrennten Zustand (keinen Zweig zugeordnet) funktioniert der Commit-Vorgang normal, aber benannte Zweige werden nicht aktualisiert. (Sie können sich das so vorstellen, als würden Sie einen anonymen Zweig aktualisieren.)

Sobald Sie zu einem anderen Zweig, z. B. Master, wechseln, wird dieser Commit-Knoten (wahrscheinlich) nie wieder referenziert und dann verworfen. Beachten Sie, dass nach diesem Befehl nichts mehr auf 2eecb verweist.

Wenn Sie diesen Zustand jedoch speichern möchten, können Sie mit dem Befehl git checkout -b name einen neuen Zweig erstellen.

Zurücksetzen

Der Befehl „Zurücksetzen“ verweist den aktuellen Zweig auf einen anderen Speicherort und ändert selektiv das Arbeitsverzeichnis und den Index. Wird auch zum Kopieren von Dateien aus dem historischen Repository in den Index verwendet, ohne das Arbeitsverzeichnis zu berühren.

Wenn keine Option angegeben ist, verweist der aktuelle Zweig auf diesen Commit. Bei Verwendung der Option –hard wird auch das Arbeitsverzeichnis aktualisiert, bei Verwendung der Option –soft bleibt es unverändert.

Wenn die Versionsnummer des Einreichungspunkts nicht angegeben ist, wird standardmäßig HEAD verwendet. Auf diese Weise bleibt der Verzweigungspunkt unverändert, aber der Index wird auf den letzten Commit zurückgesetzt. Wenn die Option –hard verwendet wird, gilt das Gleiche für das Arbeitsverzeichnis.

Wenn ein Dateiname (oder die Option -p) angegeben wird, ähnelt der Arbeitseffekt dem Auschecken mit einem Dateinamen, mit der Ausnahme, dass der Index aktualisiert wird.

Merge

Der Befehl „Merge“ führt verschiedene Zweige zusammen. Vor dem Zusammenführen muss der Index mit dem aktuellen Commit übereinstimmen. Wenn ein anderer Zweig der übergeordnete Zweig des aktuellen Commits ist, führt der Befehl „merge“ nichts aus. Eine andere Situation besteht darin, dass der aktuelle Commit der Großelternteil eines anderen Zweigs ist, was zu einer schnellen Zusammenführung führt. Der Zeiger wird einfach verschoben und ein neuer Commit generiert.

Ansonsten ist es eine echte Fusion. Standardmäßig wird eine Drei-Wege-Zusammenführung zwischen dem aktuellen Commit (ed489, siehe unten) und einem anderen Commit (33104) und ihrem gemeinsamen Großelternknoten (b325c) durchgeführt [4]. Das Ergebnis besteht darin, zuerst das aktuelle Verzeichnis und den Index zu speichern und dann zusammen mit dem übergeordneten Knoten 33104 ein neues Commit durchzuführen.

Cherry Pick

Der Befehl „cherry-pick“ „kopiert“ einen Commit-Knoten und führt einen identischen neuen Commit für den aktuellen Zweig durch.

Rebase

Rebase ist eine Alternative zum Zusammenführen von Befehlen. Beim Zusammenführen werden zwei übergeordnete Zweige zu einem Commit zusammengeführt, und der Commit-Verlauf ist nicht linear. Beim Rebasing wird der Verlauf eines anderen Zweigs im aktuellen Zweig wiedergegeben, und der Commit-Verlauf ist linear. Im Wesentlichen handelt es sich hierbei um eine linearisierte automatische Rosinenpickerei.

Die oben genannten Befehle werden alle im Themenzweig ausgeführt, nicht im Hauptzweig. Wiederholen Sie den Vorgang im Hauptzweig und verweisen Sie den Zweig auf den neuen Knoten. Beachten Sie, dass auf das alte Commit nicht verwiesen wird und es recycelt wird.

Um den Umfang des Rollbacks einzuschränken, verwenden Sie die Option –onto. Der folgende Befehl gibt die letzten paar Commits des aktuellen Zweigs seit 169a6 im Hauptzweig (2c33a) wieder.

Es gibt auch git rebase –interactive, mit dem Sie einige komplexe Vorgänge bequemer ausführen können, z. B. das Verwerfen, Neuanordnen, Ändern und Zusammenführen von Commits. Es gibt keine Bilder, die dies zeigen. Weitere Informationen finden Sie hier: git-rebase(1)[5].

Der Dateiinhalt wird nicht tatsächlich im Index (.git/index) oder im Übermittlungsobjekt gespeichert, sondern in der Datenbank (.git/objects) in Form von Blobs gespeichert und mit SHA-1-Werten überprüft. Die Indexdatei listet zugehörige Blobdateien und andere Daten mit Bezeichnern auf. Bei Übermittlungen werden diese in Form eines Baums gespeichert und zusätzlich über ihre Hashwerte identifiziert. Der Baum entspricht dem Ordner im Arbeitsverzeichnis, und der im Baum enthaltene Baum oder das Blob-Objekt entspricht dem entsprechenden Unterverzeichnis und der entsprechenden Datei. Jede Übermittlung speichert den Identifikationscode ihres übergeordneten Baums.

Wenn Sie mit getrenntem HEAD einreichen, wird die letzte Übermittlung vom Reflog für HEAD referenziert. Aber es wird nach einer Weile ungültig und wird schließlich recycelt, ähnlich wie git commit –amend oder git rebase.

Empfohlenes Lernen: „Git Tutorial“

Das obige ist der detaillierte Inhalt vonAusführliche Erklärung mit Bildern und Text! Verstehen Sie, wie Git funktioniert. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!