7.7 Git Tools - Reset Demystified

Ein einfacherer Weg, über reset und checkout nachzudenken, ist das mentale Modell, dass Git ein Inhaltsverwalter von drei verschiedenen Bäumen ist. Mit "Baum" meinen wir hier eigentlich "Sammlung von Dateien", nicht speziell die Datenstruktur. Es gibt einige Fälle, in denen der Index nicht genau wie ein Baum funktioniert, aber für unsere Zwecke ist es einfacher, ihn vorerst so zu betrachten.

Git als System verwaltet und manipuliert im normalen Betrieb drei Bäume

Git's typischer Workflow besteht darin, Snapshots Ihres Projekts in aufeinander aufbauend besseren Zuständen zu speichern, indem diese drei Bäume manipuliert werden.

Visualisieren wir diesen Prozess: Nehmen wir an, Sie gehen in ein neues Verzeichnis mit einer einzelnen Datei. Wir nennen diese Version **v1** der Datei und kennzeichnen sie in Blau. Jetzt führen wir git init aus, was ein Git-Repository mit einer HEAD-Referenz erstellt, die auf den ungeborenen master-Branch zeigt.

Zu diesem Zeitpunkt enthält nur der Baum des Arbeitsverzeichnisses Inhalt.

Jetzt wollen wir diese Datei committen, also verwenden wir git add, um den Inhalt aus dem Arbeitsverzeichnis zu nehmen und in den Index zu kopieren.

Dann führen wir git commit aus, was den Inhalt des Index nimmt und ihn als dauerhaften Snapshot speichert, ein Commit-Objekt erstellt, das auf diesen Snapshot zeigt, und master aktualisiert, sodass es auf diesen Commit zeigt.

Wenn wir git status ausführen, sehen wir keine Änderungen, da alle drei Bäume gleich sind.

Jetzt wollen wir diese Datei ändern und committen. Wir gehen den gleichen Prozess durch; zuerst ändern wir die Datei in unserem Arbeitsverzeichnis. Nennen wir dies **v2** der Datei und kennzeichnen sie in Rot.

Wenn wir jetzt git status ausführen, sehen wir die Datei in Rot als "Änderungen nicht für den Commit vorbereitet", da dieser Eintrag zwischen dem Index und dem Arbeitsverzeichnis abweicht. Als nächstes führen wir git add darauf aus, um sie in unseren Index zu übertragen.

Zu diesem Zeitpunkt, wenn wir git status ausführen, sehen wir die Datei in Grün unter "Änderungen zum Committen", da der Index und HEAD abweichen – das heißt, unser vorgeschlagener nächster Commit unterscheidet sich nun von unserem letzten Commit. Schließlich führen wir git commit aus, um den Commit abzuschließen.

Nun gibt uns git status keine Ausgabe mehr, da alle drei Bäume wieder gleich sind.

Das Wechseln von Branches oder das Klonen durchläuft einen ähnlichen Prozess. Wenn Sie einen Branch auschecken, ändert dies **HEAD**, sodass er auf die neue Branch-Referenz zeigt, füllt Ihren **Index** mit dem Snapshot dieses Commits und kopiert dann den Inhalt des **Index** in Ihr **Arbeitsverzeichnis**.

Der Befehl reset ergibt in diesem Kontext mehr Sinn.

Für die Zwecke dieser Beispiele sagen wir, dass wir file.txt erneut geändert und ein drittes Mal committet haben. Unsere Historie sieht also jetzt so aus

Gehen wir nun genau durch, was reset tut, wenn Sie es aufrufen. Es manipuliert diese drei Bäume direkt auf eine einfache und vorhersagbare Weise. Es führt bis zu drei grundlegende Operationen durch.

Das deckt das Verhalten von reset in seiner Grundform ab, aber Sie können ihm auch einen Pfad angeben, auf den er angewendet werden soll. Wenn Sie einen Pfad angeben, überspringt reset Schritt 1 und beschränkt die übrigen Aktionen auf eine bestimmte Datei oder eine Gruppe von Dateien. Das ergibt eigentlich Sinn – HEAD ist nur ein Zeiger, und Sie können nicht auf einen Teil eines Commits und auf einen Teil eines anderen zeigen. Aber der Index und das Arbeitsverzeichnis *können* teilweise aktualisiert werden, so dass reset mit den Schritten 2 und 3 fortfährt.

Nehmen wir also an, wir führen git reset file.txt aus. Diese Form (da Sie weder einen Commit-SHA-1 oder Branch angegeben noch --soft oder --hard angegeben haben) ist eine Kurzform für git reset --mixed HEAD file.txt, was Folgendes bewirkt:

Es kopiert also im Wesentlichen file.txt von HEAD in den Index.

Dies hat den praktischen Effekt, die Datei *un-stagen*. Wenn wir uns das Diagramm für diesen Befehl ansehen und darüber nachdenken, was git add tut, sind sie exakte Gegensätze.

Deshalb schlägt die Ausgabe des Befehls git status vor, dass Sie dies ausführen, um eine Datei zu un-stagen (siehe Entfernen einer gestagten Datei für mehr dazu).

Wir könnten Git auch einfach nicht davon ausgehen lassen, dass wir "die Daten von HEAD ziehen" meinten, indem wir einen bestimmten Commit angeben, von dem wir diese Dateiversion ziehen wollen. Wir würden einfach etwas wie git reset eb43bf file.txt ausführen.

Dies bewirkt im Wesentlichen dasselbe, als hätten wir den Inhalt der Datei in der Arbeitskopie auf **v1** zurückgesetzt, git add darauf ausgeführt und sie dann wieder auf **v3** zurückgesetzt (ohne tatsächlich all diese Schritte zu durchlaufen). Wenn wir jetzt git commit ausführen, wird eine Änderung aufgezeichnet, die diese Datei auf **v1** zurücksetzt, obwohl wir sie nie wieder in unserem Arbeitsverzeichnis hatten.

Es ist auch interessant zu beachten, dass der Befehl reset, wie git add, eine Option --patch akzeptiert, um Inhalte Hunk für Hunk zu un-stagen. Sie können also Inhalte selektiv un-stagen oder zurücksetzen.

Betrachten wir, wie man mit dieser neu gewonnenen Macht etwas Interessantes tun kann – Commits zusammenfassen (Squashing).

Nehmen wir an, Sie haben eine Reihe von Commits mit Nachrichten wie "Ups.", "WIP" und "Habe diese Datei vergessen". Sie können reset verwenden, um sie schnell und einfach in einen einzigen Commit zusammenzufassen, der Sie wirklich schlau aussehen lässt. Commits zusammenfassen zeigt eine andere Möglichkeit, dies zu tun, aber in diesem Beispiel ist es einfacher, reset zu verwenden.

Sagen wir, Sie haben ein Projekt, bei dem der erste Commit eine Datei hat, der zweite Commit eine neue Datei hinzufügt und die erste ändert, und der dritte Commit die erste Datei erneut ändert. Der zweite Commit war ein Arbeitsentwurf und Sie möchten ihn zusammenfassen.

Sie können git reset --soft HEAD~2 ausführen, um den HEAD-Branch zu einem älteren Commit zurückzubewegen (dem aktuellsten Commit, den Sie behalten möchten)

Und dann einfach erneut git commit ausführen

Jetzt sehen Sie, dass Ihre erreichbare Historie, die Historie, die Sie pushen würden, jetzt so aussieht, als hätten Sie einen Commit mit file-a.txt **v1** gehabt, dann einen zweiten, der sowohl file-a.txt zu **v3** geändert als auch file-b.txt hinzugefügt hat. Der Commit mit der **v2**-Version der Datei ist nicht mehr in der Historie.

Schließlich fragen Sie sich vielleicht, was der Unterschied zwischen checkout und reset ist. Wie reset manipuliert checkout die drei Bäume, und es verhält sich etwas anders, je nachdem, ob Sie dem Befehl einen Dateipfad geben oder nicht.

Hoffentlich verstehen Sie nun den Befehl reset besser und fühlen sich damit wohler, sind aber wahrscheinlich immer noch etwas verwirrt, wie genau er sich von checkout unterscheidet und können sich unmöglich alle Regeln der verschiedenen Aufrufe merken.

Hier ist eine Spickzettel, welche Befehle welche Bäume beeinflussen. Die Spalte "HEAD" liest "REF", wenn der Befehl die Referenz (Branch) bewegt, auf die HEAD zeigt, und "HEAD", wenn er HEAD selbst bewegt. Achten Sie besonders auf die Spalte "WD Safe?" – wenn dort **NEIN** steht, überlegen Sie kurz, bevor Sie diesen Befehl ausführen.