Git Reset und Reflog

Einführung

Willkommen, Git-Zeitreisender! Heute werden wir zwei leistungsstarke Git-Funktionen erkunden, die Ihnen eine beispiellose Kontrolle über die Historie Ihres Repositorys geben werden: git reset und git reflog. Diese Tools sind wie die erweiterten Steuerungen Ihrer Git-Zeitreise-Maschine und ermöglichen es Ihnen, zwischen verschiedenen Zuständen Ihres Projekts zu wechseln und sogar "verlorene" Arbeiten wiederherzustellen.

Der Befehl git reset ist ein vielseitiges Werkzeug, das Ihnen helfen kann, Änderungen rückgängig zu machen, Dateien aus der Staging-Area zu entfernen und sogar Ihre Commit-Historie neu zu schreiben. Doch mit großer Macht kommt auch große Verantwortung, und git reset kann für Neueinsteiger etwas abschreckend sein. Hier kommt git reflog ins Spiel - es ist wie ein Sicherheitsnetz, das alle Änderungen an den Referenzen (refs) Ihres Repositorys (z. B. Branch-Tips) aufzeichnet und es Ihnen ermöglicht, sich auch von den drastischsten Resets wieder zu erholen.

In diesem Lab werden wir folgende Themen behandeln:

1. Soft Reset: Verschieben des HEADs ohne Änderung des Arbeitsverzeichnisses oder der Staging-Area
2. Mixed Reset: Entfernen von Änderungen aus der Staging-Area, während die Modifikationen im Arbeitsverzeichnis bleiben
3. Hard Reset: Komplettes Verwerfen von Änderungen
4. Verwenden des Reflogs, um sich von "zerstörerischen" Operationen zu erholen
5. Zeitbasierte Resets: Verschieben Ihres Repositorys in einen Zustand zu einem bestimmten Zeitpunkt

Am Ende dieses Labs werden Sie ein solides Verständnis davon haben, wie Sie diese leistungsstarken Git-Funktionen sicher und effektiv nutzen können. Sie werden in der Lage sein, die Historie Ihres Repositorys mit Zuversicht zu manipulieren, weil Sie wissen, dass Sie sich bei Bedarf immer wieder zurechtfinden können.

Lassen Sie uns starten und damit beginnen, git reset und reflog zu beherrschen!

Skills Graph

Einrichten Ihres Arbeitsbereichs

Bevor wir mit dem Resetten und Verwenden des Reflogs beginnen, richten wir einen Arbeitsbereich mit einigen Commits ein, an dem wir experimentieren können. Wir werden ein neues Verzeichnis erstellen, ein Git-Repository initialisieren und einige Dateien mit mehreren Commits hinzufügen.

Öffnen Sie Ihr Terminal und geben Sie diese Befehle ein:

cd ~/project
mkdir git-reset-lab
cd git-reset-lab
git init

Jetzt erstellen wir einige Dateien und erstellen eine Reihe von Commits, indem wir die folgenden Befehle in Ihr Terminal kopieren und einfügen:

echo "## Git Reset and Reflog Lab" > README.md
git add README.md
git commit -m "Initial commit"

echo "function add(a, b) { return a + b; }" > math.js
git add math.js
git commit -m "Add addition function"

echo "function subtract(a, b) { return a - b; }" >> math.js
git add math.js
git commit -m "Add subtraction function"

echo "function multiply(a, b) { return a * b; }" >> math.js
git add math.js
git commit -m "Add multiplication function"

Lassen Sie uns analysieren, was wir gerade getan haben:

1. Wir haben eine README-Datei erstellt und unseren ersten Commit vorgenommen.
2. Wir haben eine JavaScript-Datei mit einer Additionsfunktion erstellt und sie committet.
3. Wir haben eine Subtraktionsfunktion zur gleichen Datei hinzugefügt und sie committet.
4. Schließlich haben wir eine Multiplikationsfunktion hinzugefügt und sie committet.

Jetzt haben wir ein Repository mit einer Historie, an der wir experimentieren können!

Soft Reset: Verschieben des HEADs

Der erste Typ von Reset, den wir untersuchen werden, ist der "soft" Reset. Ein soft Reset verschiebt den HEAD (und den aktuellen Branch) zu einem anderen Commit, ändert aber weder die Staging-Area noch das Arbeitsverzeichnis. Dies ist nützlich, wenn Sie einige Commits "rückgängig" machen möchten, aber alle Änderungen für einen neuen Commit behalten wollen.

Lassen Sie uns einen soft Reset versuchen:

git reset --soft HEAD~1

Dieser Befehl verschiebt den HEAD um einen Commit zurück. Das ~1 bedeutet "einen Commit vor dem aktuellen". Sie können ~2, ~3 usw. verwenden, um mehrere Commits zurückzugehen.

Wenn Sie jetzt git status ausführen, werden Sie sehen, dass die Änderungen aus dem letzten Commit in der Staging-Area sind und erneut committet werden können. Die Dateien in Ihrem Arbeitsverzeichnis haben sich nicht geändert.

Dies ist nützlich in Szenarien, in denen Sie Ihre letzten paar Commits zu einem zusammenfassen ("squash") möchten. Sie können mit einem soft Reset einige Commits zurückgehen und dann einen neuen Commit mit all diesen Änderungen erstellen.

Lassen Sie uns diese Änderungen erneut mit einer neuen Nachricht committen:

git commit -m "Add subtraction and multiplication functions"

Denken Sie daran, dass ein soft Reset im Allgemeinen sicher ist (da er keine Änderungen verwirft), er ändert jedoch die Historie. Wenn Sie die ursprünglichen Commits bereits gepusht haben, müssen Sie einen force push ausführen, um den Remote-Branch zu aktualisieren, was für Mitarbeiter Probleme verursachen kann. Kommunizieren Sie immer mit Ihrem Team, bevor Sie die gemeinsame Historie ändern!

Mixed Reset: Entfernen von Änderungen aus der Staging-Area

Der nächste Typ von Reset, den wir betrachten werden, ist der "mixed" Reset. Dies ist tatsächlich der Standardmodus für git reset, wenn Sie kein Flag angeben. Ein mixed Reset verschiebt den HEAD und aktualisiert die Staging-Area entsprechend, berührt aber das Arbeitsverzeichnis nicht.

Lassen Sie uns einige Änderungen vornehmen und sie in die Staging-Area hinzufügen:

echo "function divide(a, b) { return a / b; }" >> math.js
git add math.js

Nun sagen wir, dass wir uns umgedacht haben und diese Änderung noch nicht in die Staging-Area aufnehmen möchten. Wir können einen mixed Reset verwenden:

git reset HEAD

Dies entfernt unsere Änderungen aus der Staging-Area, behält sie aber im Arbeitsverzeichnis. Wenn Sie jetzt git status ausführen, werden Sie sehen, dass math.js geändert, aber nicht in der Staging-Area ist.

Der mixed Reset ist nützlich, wenn Sie einige Änderungen in die Staging-Area aufgenommen haben, aber dann entscheiden, dass Sie sie noch nicht committen möchten. Vielleicht möchten Sie die Änderungen noch einmal überprüfen oder weitere Modifikationen vornehmen, bevor Sie sie in die Staging-Area aufnehmen.

Denken Sie daran, dass im Gegensatz zum soft Reset der mixed Reset die Staging-Area ändert. Allerdings ist er dennoch sicher in dem Sinne, dass er keine Ihrer Arbeiten verwirft - alles befindet sich immer noch in Ihrem Arbeitsverzeichnis.

Hard Reset: Verwerfen von Änderungen

Der dritte und drastischste Typ von Reset ist der "hard" Reset. Ein hard Reset verschiebt den HEAD, aktualisiert die Staging-Area und aktualisiert auch das Arbeitsverzeichnis, sodass alle drei übereinstimmen. Dies bedeutet, dass alle Änderungen seit dem Commit, auf den Sie zurücksetzen, verworfen werden.

Lassen Sie uns einen hard Reset versuchen:

git add math.js
git commit -m "Add division function"
git status

git reset --hard HEAD~1

Dies fügt die Divisionsfunktion zur Staging-Area hinzu, committet sie und führt dann einen hard Reset zum vorherigen Commit durch, wodurch der letzte Commit effektiv "rückgängig" gemacht und die Änderungen verworfen werden.

Wenn Sie sich jetzt math.js ansehen, werden Sie feststellen, dass die Divisionsfunktion weg ist. Es ist, als hätten wir sie nie geschrieben.

Ein hard Reset ist leistungsstark, aber gefährlich. Er ist nützlich, wenn Sie einige Arbeiten vollständig verwerfen und von einem früheren Commit aus neu beginnen möchten. Seien Sie jedoch sehr vorsichtig mit ihm, da er Änderungen dauerhaft verwerfen kann.

Überprüfen Sie immer zweimal, dass Sie auf den richtigen Commit zurücksetzen, bevor Sie einen hard Reset durchführen. Wenn Sie unsicher sind, ist es sicherer, einen soft oder mixed Reset zu verwenden oder einen neuen Branch zu erstellen, bevor Sie experimentieren.

Verwenden des Reflogs zum Wiederherstellen verlorener Commits

Nun, was passiert, wenn Sie feststellen, dass Sie die Divisionsfunktion nicht verwerfen wollten? Hier kommt git reflog ins Spiel. Das Reflog ist ein Logbuch aller Positionen, an denen sich der HEAD in Ihrem lokalen Repository befand. Es ist wie eine Super-Historie, die sogar Befehle zur Historieänderung wie reset aufzeichnet.

Lassen Sie uns das Reflog ansehen:

git reflog

Sie sollten eine Liste aller kürzlich ausgeführten Aktionen sehen, einschließlich Ihrer Resets. Jeder Eintrag hat einen HEAD@{n}-Bezeichner.

Um Ihren verlorenen Commit wiederherzustellen, können Sie auf den Zustand vor Ihrem hard Reset zurücksetzen:

git reset --hard HEAD@{1}

Dies setzt den Zustand des HEADs auf den Zustand vor Ihrer letzten Aktion zurück (die war der hard Reset).

Schauen Sie sich jetzt math.js an, und Sie sollten sehen, dass Ihre Divisionsfunktion wieder da ist!

cat math.js

function add(a, b) { return a + b; }
function subtract(a, b) { return a - b; }
function multiply(a, b) { return a * b; }
function divide(a, b) { return a / b; }

Das Reflog ist ein leistungsstarkes Sicherheitsnetz, das es Ihnen ermöglicht, aus fast jedem Git-Fehler wiederherzustellen. Denken Sie jedoch daran, dass es lokal auf Ihrem Computer gespeichert ist und nur temporär gültig ist (Einträge werden normalerweise 30 bis 90 Tage lang aufbewahrt). Es ist kein Ersatz für regelmäßige Backups oder für das Pushen Ihrer Arbeit in ein Remote-Repository.

Zeitbasierte Resets

Git ermöglicht es Ihnen auch, Ihr Repository auf seinen Zustand zu einem bestimmten Zeitpunkt zurückzusetzen. Dies kann nützlich sein, wenn Sie ungefähr wissen, wann sich Ihr Repository in dem Zustand befand, zu dem Sie zurückkehren möchten.

Lassen Sie uns einen zeitbasierten Reset versuchen:

git reset --hard master@{"1 hour ago"}

Dies setzt Ihr Repository auf seinen Zustand von einer Stunde ago zurück. Sie können verschiedene Zeitangaben wie "gestern", "vor 2 Tagen", "vor 3 Minuten" usw. verwenden.

Seien Sie bei zeitbasierten Resets vorsichtig, da sie weniger präzise sein können als das Zurücksetzen auf einen bestimmten Commit. Überprüfen Sie immer den Zustand Ihres Repositorys nach einem zeitbasierten Reset, um sicherzustellen, dass Sie am gewünschten Ort angekommen sind.

Denken Sie daran, dass Sie immer das Reflog verwenden können, um einen zeitbasierten Reset rückgängig zu machen, wenn das Ergebnis nicht wie erwartet ist.

Zusammenfassung

Herzlichen Glückwunsch, Git-Zeitlord! Sie haben gerade einige der mächtigsten und zugleich gefährlichsten Befehle von Git beherrscht. Lassen Sie uns die wichtigsten Konzepte, die wir behandelt haben, noch einmal zusammenfassen:

1. Soft Reset: Verschiebt den HEAD, ohne die Staging-Area oder das Arbeitsverzeichnis zu ändern. Nützlich für das Zusammenführen von Commits (Squashing).
2. Mixed Reset: Verschiebt den HEAD und aktualisiert die Staging-Area, berührt aber das Arbeitsverzeichnis nicht. Ideal für das Entfernen von Änderungen aus der Staging-Area.
3. Hard Reset: Verschiebt den HEAD, aktualisiert die Staging-Area und das Arbeitsverzeichnis. Mächtig, aber möglicherweise zerstörerisch.
4. Reflog: Ein Sicherheitsnetz, das alle Änderungen am HEAD aufzeichnet und es Ihnen ermöglicht, aus fast jedem Git-Fehler wiederherzustellen.
5. Zeitbasierte Resets: Ermöglichen es Ihnen, Ihr Repository auf seinen Zustand zu einem bestimmten Zeitpunkt zurückzusetzen.

Denken Sie daran, dass mit großer Macht auch große Verantwortung verbunden ist. Während diese Befehle Ihnen eine unglaubliche Kontrolle über die Historie Ihres Repositorys geben, können sie auch gefährlich sein, wenn sie unvorsichtig verwendet werden. Überprüfen Sie immer zweimal, bevor Sie einen Reset durchführen, insbesondere einen hard Reset, und denken Sie daran, dass das Reflog Ihr Freund ist, wenn etwas schief geht.

Wenn Sie Ihre Git-Reise fortsetzen, üben Sie diese Befehle in einer sicheren Umgebung, bis Sie sich mit ihnen wohl fühlen. Sie sind mächtige Werkzeuge, die Ihren Git-Arbeitsablauf erheblich verbessern können, wenn sie richtig verwendet werden.

Viel Spaß beim Zurücksetzen, und möge Ihre Git-Historie immer sauber und sinnvoll sein!