7.7 Git Tools - Reset entzaubert

Eine bessere Methode, um über reset und checkout zu reflektieren, ist der gedankliche Ansatz, dass Git ein Inhaltsmanager von drei verschiedenen Bäumen ist. Mit „Baum“ meinen wir hier in Wahrheit eine „Sammlung von Dateien“, nicht speziell die Datenstruktur. Es gibt ein paar Fälle, in denen sich der Inhalt nicht genau wie ein Baum verhält, aber für unsere Zwecke ist es vorerst einfacher, auf diese Weise darüber nachzudenken.

Als System verwaltet Git im regulären Modus drei Bäume:

Der typische Arbeitsablauf von Git sieht vor, dass Sie durch die Bearbeitung dieser drei Bäume nach und nach bessere Momentaufnahmen Ihres Projekts erzeugen.

Stellen wir uns folgenden Ablauf vor: Angenommen, Sie wechseln in ein neues Verzeichnis, in dem sich eine einzige Datei befindet. Wir nennen das die v1 der Datei und kennzeichnen sie in blau. Nun führen wir git init aus, das ein Git-Repository mit einer HEAD-Referenz erzeugt, die auf den noch nicht existierenden master Branch zeigt.

Zu diesem Zeitpunkt hat nur der Verzeichnisbaum (engl working tree) des Arbeitsverzeichnisses (engl. working directory) irgendeinen Inhalt.

Nun wollen wir diese Datei committen, also benutzen wir git add, um den Inhalt im Arbeitsverzeichnis zu übernehmen und in den Index zu kopieren.

Dann führen wir git commit aus, das den Inhalt der Staging-Area (oder Index) als endgültigen Snapshot speichert, ein Commit-Objekt erzeugt, das auf diesen Snapshot zeigt, und den Branch master aktualisiert, um auf diesen Commit zu zeigen.

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

Nun wollen wir eine Änderung an dieser Datei vornehmen und sie übertragen. Wir führen den gleichen Vorgang durch. Zuerst ändern wir die Datei in unserem Arbeitsverzeichnis. Wir nennen sie v2 dieser Datei und markieren sie in rot.

Wenn wir jetzt den Befehl git status aufrufen, sehen wir die Datei in rot als „Changes not staged for commit“ (dt. Änderungen nicht zum Commit vorgemerkt), weil sich dieser Eintrag im Index zu dem im Arbeitsverzeichnis unterscheidet. Als nächstes führen wir git add aus, um sie in unseren Index zu übernehmen, d.h zur Staging-Area hinzuzufügen.

Wenn wir zu diesem Zeitpunkt git status ausführen, sehen wir die Datei in grün unter „Changes to be committed“ (dt. Änderungen zum Commit vorgemerkt), weil sich der Index und der HEAD unterscheiden – d.h. unser geplanter nächster Commit unterscheidet sich nun von unserem letzten Commit. Schließlich führen wir git commit aus, um die Daten zu übertragen.

Nun wird uns git status keine Ergebnisse liefern, weil alle drei Bäume wieder gleich sind.

Das Wechseln von Branches oder das Klonen geht ähnlich vor sich. Wenn Sie einen Branch auschecken, ändert er HEAD so, dass er auf den neuen Branch-Ref zeigt, füllt Ihre Staging-Area (bzw. Index) mit dem aktuellen Schnappschuss dieses Commits und kopiert dann den Inhalt des Index in Ihr Arbeitsverzeichnis.

Der Befehl reset macht mehr Sinn, wenn wir folgenden Fall betrachten.

Für diesen Zweck nehmen wir an, dass wir file.txt erneut modifiziert und ein drittes Mal committed hätten. Nun sieht unser Verlauf so aus:

Lassen Sie uns nun genau untersuchen, was reset bewirkt, wenn Sie es aufrufen. Es manipuliert die drei Bäume auf einfache und kalkulierbare Weise direkt. Es führt bis zu drei einfache Operationen aus.

Das deckt das Verhalten von reset in seiner Basisform ab, aber Sie können ihm auch einen Pfad angeben, auf dem er aktiv werden soll. Wenn Sie einen Pfad festlegen, überspringt reset Step 1 und beschränkt die restlichen Aktionen auf eine bestimmte Datei oder eine Gruppe von Dateien. Das macht tatsächlich Sinn – HEAD ist nur ein Pointer. Sie können nicht auf den einen Teil eines Commits und auf einen Teil eines anderen zeigen. Der Index und das Arbeitsverzeichnis können jedoch teilweise aktualisiert werden, so dass das Zurücksetzen mit den Schritten 2 und 3 fortgesetzt wird.

Nehmen wir also an, wir führen ein git reset file.txt aus. Da Sie hier keinen Commit-SHA-1 oder -Branch angegeben haben und auch nicht die Optionen --soft oder --hard verwendet haben, ist das die Kurzform für git reset --mixed HEAD file.txt. Der Befehl wird Folgendes bewirken:

Er kopiert also im Endeffekt nur file.txt von HEAD in den Index.

Das hat den praktischen Effekt, dass die Datei aus der Staging-Area entfernt wird (engl. unstage). Wenn wir uns die Abbildung für diesen Befehl ansehen und überlegen, was git add macht, sind die beiden Befehle genau gegensätzlich.

Deshalb schlägt die Anzeige des Befehls git status vor, dass Sie den Befehl git reset ausführen, um eine Datei aus der Staging-Area zu entfernen. Siehe auch Kapitel 2 Eine Datei aus der Staging-Area entfernen für weitere Informationen.

Wir könnten, ebenso einfach, Git nicht annehmen lassen, dass wir damit meinen, es soll „die Daten aus dem HEAD holen“ (engl. pull), indem wir einen bestimmten Commit angeben, aus dem diese Dateiversion gezogen werden soll. Stattdessen würden wir einfach etwas wie git reset eb43bf file.txt ausführen.

Das macht effektiv dasselbe, als ob wir den Inhalt der Datei im Arbeitsverzeichnis auf v1 geändert, git add darauf ausgeführt und dann wieder auf v3 zurückgewandelt hätten (ohne wirklich alle diese Schritte zu durchlaufen). Wenn wir jetzt git commit aufrufen, wird er eine Modifikation registrieren, die diese Datei wieder auf v1 zurücksetzt, obwohl wir sie nie wieder in unserem Arbeitsverzeichnis hatten.

Interessant ist auch, dass der reset Befehl wie auch git add die Option --patch akzeptiert, um Inhalte schrittweise zu entfernen. Sie können also selektiv Inhalte aufheben oder zurücksetzen.

Schauen wir uns an, was wir mit dieser neu entdeckten Möglichkeit machen können – das Zusammenfassen von Commits.

Angenommen, Sie hätten eine Reihe von Commits mit Nachrichten wie „Ups“, „WIP“ und „Diese Datei vergessen“. Sie können reset verwenden, um diese schnell und einfach in einem einzigen Commit zusammenzufassen, der Sie wirklich clever aussehen lässt. Commits zusammenfassen zeigt Ihnen eine andere Möglichkeit auf. In diesem Fall ist es einfacher reset zu verwenden.

Stellen wir uns vor, Sie hätten ein Projekt, bei dem der erste Commit eine Datei enthält, 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 eine unfertige Arbeit und Sie wollen diesen zusammenschieben.

Sie können git reset --soft HEAD~2 ausführen, um den HEAD-Branch zurück zu einem älteren Commit (dem neuesten Commit, den Sie behalten wollen) zu verschieben:

Danach einfach erneut git commit starten:

Jetzt können Sie sehen, dass Ihr erwünschter Verlauf, der Verlauf, den Sie pushen würden, jetzt so aussieht, als hätten Sie einen Commit mit file-a.txt v1 gemacht, dann einen zweiten, der sowohl file-a.txt zu v3 modifiziert als auch file-b.txt hinzugefügt hat. Der Commit mit der Version v2 der Datei ist nicht mehr im Verlauf enthalten.

Zum Schluss werden Sie sich vielleicht fragen, was der Unterschied zwischen checkout und reset ist. Wie reset manipuliert checkout die drei Bäume. Es ist ein bisschen unterschiedlich, je nachdem, ob Sie dem Befehl einen Dateipfad mitgeben oder nicht.

Wir hoffen, dass Sie jetzt den Befehl reset besser kennen und anwenden können. Wahrscheinlich sind Sie aber immer noch etwas unsicher, wie genau er sich von checkout unterscheidet. Sie können sich vermutlich nicht alle Regeln der verschiedenen Aufrufe merken.

Hier ist eine Tabelle, die zeigt, welche Befehle sich auf welche Bäume auswirken. In der Spalte „HEAD“ bedeutet „REF“, dass dieser Befehl die Referenz (den Branch) verschiebt, auf die HEAD zeigt. „HEAD“ signalisiert, dass er HEAD selbst verschiebt. Achten Sie besonders auf die Spalte „WD sicher?“ – wenn dort „NO“ steht, überlegen Sie sich genau, ob Sie diesen Befehl ausführen wollen.