So prüfen Sie, ob ein Git-Commit geändert wurde

Einführung

In diesem Lab lernen Sie, wie Sie feststellen können, ob ein Git-Commit geändert (amended) wurde. Wir werden den Befehl git reflog untersuchen, um die Historie der Referenzaktualisierungen anzuzeigen, die Änderungsvorgänge (amend operations) aufdecken können.

Sie werden auch lernen, wie Sie git log verwenden, um Commits zu vergleichen und die Unterschiede zwischen geänderten (amended) und nicht-geänderten Commits zu verstehen. So gewinnen Sie praktische Fähigkeiten bei der Untersuchung der Historie Ihres Repositorys.

Skills Graph

Prüfen des Git-Reflogs auf Änderungseinträge (Amend Entries)

In diesem Schritt werden wir den Befehl git reflog untersuchen und wie er uns hilft, die Historie unseres Repositorys zu sehen, einschließlich Aktionen wie das Ändern von Commits (amending commits).

Zunächst stellen wir sicher, dass wir uns in unserem Projektverzeichnis befinden. Öffnen Sie Ihr Terminal und navigieren Sie zum Verzeichnis my-time-machine:

cd ~/project/my-time-machine

Jetzt verwenden wir den Befehl git reflog, um die Historie unseres Repositorys anzuzeigen. Der reflog (Referenzprotokoll) protokolliert Aktualisierungen an den Spitzen von Branches und anderen Referenzen im Repository. Dies unterscheidet sich von git log, das die Commit-Historie anzeigt.

Geben Sie den folgenden Befehl ein:

git reflog

Sie sollten eine Ausgabe ähnlich der folgenden sehen:

a1b2c3d (HEAD -> master) HEAD@{0}: commit: Send a message to the future
a1b2c3d (HEAD -> master) HEAD@{1}: initial commit (amend): Send a message to the future
e4f5g6h HEAD@{2}: commit (initial): Send a message to the future

Lassen Sie uns diese Ausgabe analysieren:

• Jede Zeile repräsentiert eine Aktion, die eine Referenz (wie HEAD) aktualisiert hat.
• HEAD@{0} ist die neueste Aktion, HEAD@{1} ist die Aktion davor und so weiter.
• Der erste Teil jeder Zeile (a1b2c3d, e4f5g6h) ist der Commit-Hash. Beachten Sie, wie sich der Commit-Hash nach einem "amend"-Vorgang ändert.
• Der Text nach dem Commit-Hash beschreibt die Aktion, wie commit, initial commit (amend) oder commit (initial).

Der git reflog ist ein leistungsstarkes Werkzeug, um verlorene Commits wiederherzustellen oder die Abfolge der Operationen zu verstehen, die zum aktuellen Zustand Ihres Repositorys geführt haben. Er zeigt Ihnen, wo sich Ihr HEAD befand, auch wenn diese Commits nicht mehr Teil der Historie eines Branches sind (z. B. nach einem Amend oder Rebase).

In der Beispielausgabe können Sie einen Eintrag wie initial commit (amend) sehen. Dies zeigt an, dass der Initial-Commit geändert wurde. Das Ändern eines Commits ersetzt den letzten Commit durch einen neuen Commit, der die Änderungen enthält, die Sie staged haben. Während git log nur den endgültigen, geänderten Commit anzeigt, zeigt git reflog sowohl den ursprünglichen Initial-Commit als auch den geänderten an.

Das Verständnis von git reflog ist entscheidend für die Navigation in der Historie Ihres Projekts, insbesondere wenn Sie Befehle verwenden, die die Historie neu schreiben, wie git commit --amend.

Verwenden von git log zum Vergleichen von Commits

In diesem Schritt werden wir den Befehl git log verwenden, um die Commit-Historie anzuzeigen und zu verstehen, wie er sich von git reflog unterscheidet, insbesondere nach der Verwendung von git commit --amend.

Stellen Sie sicher, dass Sie sich immer noch im Verzeichnis ~/project/my-time-machine befinden.

Jetzt lassen Sie uns die Commit-Historie mit git log anzeigen:

git log --oneline

Die Option --oneline bietet eine kompakte Ansicht der Commit-Historie, wobei jeder Commit in einer einzigen Zeile angezeigt wird.

Sie sollten eine Ausgabe ähnlich der folgenden sehen:

a1b2c3d (HEAD -> master) Send a message to the future

Vergleichen Sie diese Ausgabe mit der Ausgabe von git reflog im vorherigen Schritt. Beachten Sie, dass git log nur einen Commit anzeigt, nämlich den endgültigen, geänderten Commit. Es zeigt nicht den ursprünglichen Initial-Commit an, der durch den Amend-Vorgang ersetzt wurde.

Dies ist ein wesentlicher Unterschied zwischen git log und git reflog. git log zeigt die Historie der Commits an, die von der Spitze des aktuellen Branches aus erreichbar sind, während git reflog die Historie der Positionen von HEAD und anderen Referenzen anzeigt.

Denken Sie sich git log als die offizielle veröffentlichte Historie Ihres Projekts, während git reflog Ihr persönliches Tagebuch aller Aktionen in Ihrem Repository ist.

Sie können auch git log verwenden, um verschiedene Commits zu vergleichen. Obwohl wir derzeit nur einen Commit in unserer Historie haben, könnten Sie in einem echten Projekt mit mehreren Commits Befehle wie git log commit1..commit2 verwenden, um die Commits zwischen zwei bestimmten Punkten in der Historie anzuzeigen, oder git diff commit1 commit2, um die genauen Änderungen zwischen zwei Commits zu sehen.

Für den Moment ist es wichtig, zu verstehen, dass git log die Commit-Historie und git reflog die Historie der Referenzaktualisierungen anzeigt.

Testen von nicht geänderten Commits

In diesem Schritt werden wir einen neuen Commit erstellen, ohne die --amend-Option zu verwenden, und beobachten, wie er in git log und git reflog erscheint. Dies wird Ihnen helfen, besser zu verstehen, wie diese Befehle die Historie unterschiedlich verfolgen.

Zunächst fügen wir unserer message.txt-Datei etwas mehr Inhalt hinzu. Wir fügen eine neue Zeile an:

echo "Hello again, Future Me!" >> message.txt

Der >>-Operator fügt den Text an die bestehende Datei an, anstatt sie zu überschreiben.

Jetzt überprüfen wir den Status, um die Änderungen zu sehen:

git status

Sie sollten eine Ausgabe sehen, die anzeigt, dass message.txt geändert wurde:

On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   message.txt

no changes added to commit (use "git add" and/or "git commit -a")

Als Nächstes müssen wir die Änderungen stage'n:

git add message.txt

Und jetzt erstellen wir einen neuen Commit, ohne den vorherigen zu ändern:

git commit -m "Add another message"

Sie sollten eine Ausgabe sehen, die den neuen Commit bestätigt:

[master 1a2b3c4] Add another message
 1 file changed, 1 insertion(+)

Jetzt überprüfen wir erneut git log:

git log --oneline

Diesmal sollten Sie zwei Commits sehen:

1a2b3c4 (HEAD -> master) Add another message
a1b2c3d Send a message to the future

Beide Commits sind in git log sichtbar, da der zweite Commit auf dem ersten aufgebaut wurde und die Historie des Branches erweitert.

Schließlich überprüfen wir git reflog:

git reflog

Sie sollten eine Ausgabe ähnlich der folgenden sehen:

1a2b3c4 (HEAD -> master) HEAD@{0}: commit: Add another message
1a2b3c4 (HEAD -> master) HEAD@{1}: commit (amend): Send a message to the future
e4f5g6h HEAD@{2}: commit (initial): Send a message to the future

Beachten Sie, dass git reflog alle Aktionen anzeigt: den Initial-Commit, den geänderten Initial-Commit und den neuen Commit, den wir gerade erstellt haben. Jede Aktion, die HEAD bewegt hat, wird aufgezeichnet.

Dieser Schritt zeigt, dass wenn Sie einen neuen Commit ohne --amend erstellen, sowohl git log als auch git reflog den neuen Commit anzeigen, aber git reflog weiterhin die Historie des geänderten Commits beibehält, was git log nicht tut.

Zusammenfassung

In diesem Lab haben wir gelernt, wie man prüft, ob ein Git-Commit geändert (amended) wurde. Wir haben uns mit dem Befehl git reflog vertraut gemacht, der die Historie der Aktualisierungen von Referenzen wie HEAD bereitstellt und uns ermöglicht, Aktionen wie das Ändern von Commits zu sehen. Durch die Untersuchung der reflog-Ausgabe können wir Einträge identifizieren, die einen Amend-Vorgang anzeigen, und beobachten, wie sich der Commit-Hash nach einer solchen Aktion ändert.

Wir haben auch gelernt, dass git reflog ein wertvolles Werkzeug ist, um die Abfolge der Operationen in einem Repository zu verstehen, auch für Commits, die nicht mehr direkt über git log zugänglich sind. Dies hilft bei der Wiederherstellung von verlorenen Arbeiten oder der Diagnose von Problemen in der Repository-Historie.