Grundlegende Verwendung

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

• git add filesDie aktuelle Datei in den Staging-Bereich legen.
• git commitEinen Snapshot des Staging-Bereichs erzeugen und committen.
• git reset -- filesWird verwendet, um den letztengit add files, du kannst auchgit resetum alle Dateien im Staging-Bereich rückgängig zu machen.
• git checkout -- filesDateien aus dem Staging-Bereich in das Arbeitsverzeichnis kopieren, um lokale Änderungen zu verwerfen.

Sie könnengit reset -p, git checkout -p, oder git add -pum in den interaktiven Modus zu wechseln.

Du kannst den Staging-Bereich auch überspringen und Dateien direkt aus dem Repository abrufen oder Code direkt committen.

• git commit -a Entspricht der Ausführung vongit addHinzufügen aller Dateien im aktuellen Verzeichnis zum Staging-Bereich und anschließendes Ausführen.git commit.
• git commit filesEinen Commit erstellen, der den letzten Commit plus einen Snapshot der Dateien im Arbeitsverzeichnis enthält. Und die Dateien werden zum Staging-Bereich hinzugefügt.
• git checkout HEAD -- filesZurückrollen, um den letzten Commit zu kopieren.

Konventionen

Im folgenden Text werden Bilder in der unten dargestellten Form verwendet.

Die grünen 5-stelligen Zeichenfolgen repräsentieren Commit-IDs und verweisen jeweils auf ihre Elternknoten. Branches werden orange dargestellt und verweisen jeweils auf einen bestimmten Commit. Der aktuelle Branch wird durch dieHEAD-Kennung identifiziert. Dieses Bild zeigt die letzten 5 Commits,ed489ist der neueste Commit.master-Branch zeigt auf diesen Commit, ein weiterermaint-Branch zeigt auf den Großeltern-Commit-Knoten.

Befehlsdetails

Diff

Es gibt viele Möglichkeiten, die Unterschiede zwischen zwei Commits anzuzeigen. Nachfolgend einige Beispiele.

Commit

Beim Committen verwendet git die Dateien im Staging-Bereich, um einen neuen Commit zu erstellen, und legt den aktuellen Knoten als Elternknoten fest. Dann richtet er den aktuellen Branch auf den neuen Commit-Knoten aus. In der folgenden Abbildung ist der aktuelle Branchmaster. Vor dem Ausführen des Befehls,masterzeigt aufed489, nach dem Commit zeigtmasterauf den neuen Knotenf0cecund verwendeted489als Elternknoten.

Selbst wenn der aktuelle Branch der Großelternknoten eines Commits ist, verfährt git genauso. In der folgenden Abbildung wird ammaster-Großelternknoten des Branches auf demmaint-Branch ein Commit erstellt, wodurch1800berzeugt wird. Auf diese Weise,maintDer Branch ist nicht mehrmasterder Großelternknoten des Branches. An diesem Punkt ist Merging (oder Rebasing) erforderlich.

Wenn Sie einen Commit ändern möchten, verwenden Siegit commit --amend. git erstellt einen neuen Commit mit demselben Elternknoten wie der aktuelle Commit, und der alte Commit wird verworfen.

Ein weiteres Beispiel ist ein detached-HEAD-Commit, der später besprochen wird.

Checkout

Der checkout-Befehl wird verwendet, um Dateien aus einem historischen Commit (oder der Staging-Bereich) in das Arbeitsverzeichnis zu kopieren, und kann auch zum Wechseln von Branches verwendet werden.

Wenn ein Dateiname angegeben wird (oder die Option -p aktiviert ist oder sowohl der Dateiname als auch die Option -p zusammen aktiviert sind), kopiert git Dateien aus dem angegebenen Commit in den Staging-Bereich und das Arbeitsverzeichnis. Zum Beispiel,git checkout HEAD~ foo.cwird vom Commit-KnotenHEAD~(d. h. dem Elternknoten des aktuellen Commit-Knotens),foo.cdie Datei in das Arbeitsverzeichnis kopieren und sie zum Staging-Bereich hinzufügen. (Wenn im Befehl kein Commit-Knoten angegeben ist, wird der Inhalt aus dem Staging-Bereich kopiert.) Beachten Sie, dass sich der aktuelle Branch nicht ändert.

Wenn kein Dateiname angegeben ist, aber ein (lokaler) Branch angegeben wird, dann bewegt sich derHEAD-Bezeichner zu diesem Branch (das heißt, wir "wechseln" zu diesem Branch), und danach werden die Inhalte des Staging-Bereichs und des Arbeitsverzeichnisses mit dem entsprechenden Commit-KnotenHEADübereinstimmen. Alle Dateien im neuen Commit-Knoten (a47c3 in der Abbildung unten) werden kopiert (in den Staging-Bereich und das Arbeitsverzeichnis); Dateien, die nur im alten Commit-Knoten (ed489) existieren, werden gelöscht; Dateien, die zu keinem der oben genannten gehören, werden ignoriert und bleiben unberührt.

Wenn weder ein Dateiname noch ein Branchname angegeben ist, sondern ein Tag, ein Remote-Branch, ein SHA-1-Wert oder etwas Ähnliches wiemaster~3, erhalten Sie einen anonymen Branch, genanntdetached HEAD(detachedHEADBezeichner). Dies macht es bequem, zwischen historischen Versionen zu wechseln. Wenn Sie beispielsweise git Version 1.6.6.1 kompilieren möchten, können Sie ausführengit checkout v1.6.6.1(dies ist ein Tag, kein Branch-Name), kompilieren, installieren und dann zu einem anderen Branch zurückwechseln, zum Beispielgit checkout master. Wenn ein Commit-Vorgang jedoch einen "detached HEAD" betrifft, ist sein Verhalten leicht unterschiedlich; siehe unten für Details.

Commit-Vorgänge, wenn sich der HEAD-Bezeichner in einem detached Zustand befindet

WennHEADWenn er sich in einem detached Zustand befindet (an keinen Branch angehängt), können Commit-Vorgänge normal ablaufen, aber kein benannter Branch wird aktualisiert. (Man kann sich das als Aktualisierung eines anonymen Branches vorstellen.)

Sobald Sie danach zu einem anderen Branch wechseln, zum Beispielmaster, wird dieser Commit-Knoten möglicherweise nie wieder referenziert und wird verworfen. Beachten Sie, dass nach diesem Befehl nichts auf2eecb verweisen wird。

Wenn Sie diesen Zustand jedoch speichern möchten, können Sie den Befehl verwendengit checkout -b nameum einen neuen Branch zu erstellen.

Zurücksetzen

Der reset-Befehl zeigt den aktuellen Branch auf eine andere Stelle und ändert selektiv das Arbeitsverzeichnis und den Index. Er wird auch verwendet, um Dateien aus dem historischen Repository in den Index zu kopieren, ohne das Arbeitsverzeichnis zu ändern.

Wenn keine Option angegeben wird, zeigt der aktuelle Branch auf diesen Commit. Wenn die--hardOption verwendet wird, wird auch das Arbeitsverzeichnis aktualisiert; wenn die--softOption verwendet wird, ändert sich weder das eine noch das andere.

Wenn keine Commit-Versionsnummer angegeben wird, standardmäßigHEAD. Auf diese Weise bleibt der Branch-Zeiger unverändert, aber der Index wird auf den letzten Commit zurückgesetzt; wenn die--hardOption verwendet wird, ist das Arbeitsverzeichnis ebenfalls dasselbe. Wenn ein Dateiname angegeben wird (oder-pOption), ist die Wirkung ähnlich wie bei checkout mit einem Dateinamen, außer dass der Index aktualisiert wird.

Merge

Der Merge-Befehl führt verschiedene Branches zusammen. Vor dem Mergen muss der Index mit dem aktuellen Commit identisch sein. Wenn ein anderer Branch der Großvater-Commit des aktuellen Commits ist, bewirkt der Merge-Befehl nichts. Der andere Fall ist, wenn der aktuelle Commit der Großvater-Commit eines anderen Branches ist, was zu einemFast-ForwardMerge. Der Zeiger bewegt sich einfach und erzeugt keinen neuen Commit.

Andernfalls ist es ein echter Merge. Standardmäßig führen der aktuelle Commit (ed489wie unten gezeigt) und ein anderer Commit (33104) sowie ihr gemeinsamer Großvater-Knoten (b325c) einenDrei-Wege-Merge durch.. Das Ergebnis ist, dass zuerst das aktuelle Verzeichnis und der Index gespeichert werden und dann zusammen mit dem Eltern-Knoten33104ein neuer Commit erstellt wird.

Cherry Pick

Der cherry-pick-Befehl "kopiert" einen Commit-Knoten und erstellt einen identischen neuen Commit im aktuellen Branch.

Rebase

Rebasing ist eine Alternative zum Merge-Befehl. Merge kombiniert zwei Eltern-Branches zu einem Commit, und die Commit-Historie ist nicht linear. Rebasing spielt die Historie eines anderen Branches auf dem aktuellen Branch erneut ab und macht die Commit-Historie linear. Im Wesentlichen ist dies ein automatisierter cherry-pick, der linearisiert.

Die oben genannten Befehle werden alle auf demtopicBranch ausgeführt, nicht auf demmasterBranch; auf demmasterBranch werden sie erneut abgespielt, und der Branch zeigt auf den neuen Knoten. Beachten Sie, dass die alten Commits nicht referenziert werden und schließlich aufgeräumt werden.

Um den Rollback-Bereich zu begrenzen, verwenden Sie die--ontoOption. Der folgende Befehl spielt auf demmaster-Branch den aktuellen Branch von169a6den jüngsten Commits an erneut ab, das heißt,2c33a。

Es gibt auchgit rebase --interactiveum es Ihnen zu erleichtern, einige komplexe Operationen auszuführen, wie z. B. das Verwerfen, Neuordnen, Ändern und Zusammenführen von Commits. Es gibt keine Abbildungen, die diese veranschaulichen; siehe hier für Details:git-rebase(1)

Technische Hinweise

Dateiinhalte werden nicht tatsächlich im Index (.git/index) oder in Commit-Objekten gespeichert, sondern separat in der Datenbank als Blobs (.git/objects) gespeichert und mit SHA-1-Werten verifiziert. Die Indexdatei verwendet Identifikationscodes, um relevante Blob-Dateien und andere Daten aufzulisten. Commits werden in einem Baum (tree-Form, die ebenfalls durch den entsprechenden Hashwert identifiziert wird. Trees entsprechen Ordnern im Arbeitsverzeichnis, und die in einem Tree enthaltenen Trees oder Blob-Objekte entsprechen den entsprechenden Unterverzeichnissen und Dateien. Jeder Commit speichert den Identifikationscode seines übergeordneten Trees.

Wenn Sie mit detached HEAD committen, wird der letzte Commit vom Reflog für HEAD referenziert. Aber er wird nach einer Weile ungültig und schließlich aufgeräumt, ähnlich wiegit commit --amendodergit rebaseim Wesen.

Original-Link: http://marklodato.github.io/visual-git-guide/index-zh-cn.html