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 du durch die Bearbeitung dieser drei Bäume nach und nach bessere Momentaufnahmen deines Projekts erzeugst.

Stellen wir uns folgenden Ablauf vor: Angenommen, du wechselst 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 du einen Branch auscheckst, ändert er HEAD so, dass er auf den neuen Branch-Ref zeigt, füllt deine Staging-Area (bzw. Index) mit dem aktuellen Schnappschuss dieses Commits und kopiert dann den Inhalt des Index in dein 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 committet hätten. Nun sieht unser Verlauf so aus:

Lass uns nun genau untersuchen, was reset bewirkt, wenn du es aufrufst. 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 du kannst ihm auch einen Pfad angeben, auf dem er aktiv werden soll. Wenn du einen Pfad festlegst, ü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. Du kannst 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 du hier keinen Commit-SHA-1 oder -Branch angegeben hast und auch nicht die Optionen --soft oder --hard verwendet hast, 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 du den Befehl git reset ausführst, 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 pullen“, 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. Du kannst 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, du hast eine Reihe von Commits mit Nachrichten wie „Ups“, „WIP“ und „Diese Datei vergessen“. Du kannst reset verwenden, um diese schnell und einfach in einem einzigen Commit zusammenzufassen, der dich wirklich clever aussehen lässt. Commits zusammenfassen zeigt dir eine andere Möglichkeit auf, aber in diesem Fall ist es einfacher reset zu verwenden.

Stellen wir uns vor, du hast 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 du willst diese zusammenfassen.

Du kannst git reset --soft HEAD~2 ausführen, um den HEAD-Branch zurück zu einem älteren Commit (dem neuesten Commit, den du behalten willst) zu verschieben:

Danach einfach erneut git commit ausführen:

Jetzt kannst du sehen, dass dein gewünschter Verlauf, der Verlauf, den du pushen möchtest, jetzt so aussieht, als hättest du einen Commit mit file-a.txt v1 gemacht. Anschließend hättest du einen zweiten gemacht, 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 wirst du dich 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 du dem Befehl einen Dateipfad mitgibst oder nicht.

Wir hoffen, dass du jetzt den Befehl reset besser kennen und anwenden kannst. Wahrscheinlich bist du aber immer noch etwas unsicher, wie genau er sich von checkout unterscheidet. Du kannst dir 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. Achte besonders auf die Spalte „WD sicher?“. Wenn dort „NO“ steht, überlege dir genau, ob du diesen Befehl ausführen willst.