So prüfen Sie, ob ein Git-Tag auf einen bestimmten Commit verweist

GitGitBeginner
Jetzt üben

💡 Dieser Artikel wurde von AI-Assistenten übersetzt. Um die englische Version anzuzeigen, können Sie hier klicken

Einführung

In diesem Lab lernen Sie, wie Sie prüfen können, ob ein Git-Tag (Git-Markierung) auf einen bestimmten Commit zeigt. Wir werden den Befehl git rev-parse untersuchen, um den Commit-Hash (Bestandsnummer des Commits) abzurufen, der einem Tag zugeordnet ist, und ihn dann mit dem tatsächlichen Commit-Hash aus dem Git-Log vergleichen.

Durch praktische Schritte erstellen Sie ein einfaches Git-Repository, fügen eine Datei hinzu, erstellen einen Commit und erstellen ein Tag. Anschließend verwenden Sie git rev-parse, um den Commit-Hash des Tags zu ermitteln und seine Genauigkeit zu überprüfen, indem Sie ihn mit dem aus dem Git-Log erhaltenen Commit-Hash vergleichen. Abschließend testen Sie diesen Prozess mit verschiedenen Tags, um Ihr Verständnis zu festigen.


Skills Graph

%%%%{init: {'theme':'neutral'}}%%%% flowchart RL git(("Git")) -.-> git/BranchManagementGroup(["Branch Management"]) git(("Git")) -.-> git/BasicOperationsGroup(["Basic Operations"]) git/BasicOperationsGroup -.-> git/add("Stage Files") git/BasicOperationsGroup -.-> git/commit("Create Commit") git/BranchManagementGroup -.-> git/log("Show Commits") git/BranchManagementGroup -.-> git/tag("Git Tags") subgraph Lab Skills git/add -.-> lab-560115{{"So prüfen Sie, ob ein Git-Tag auf einen bestimmten Commit verweist"}} git/commit -.-> lab-560115{{"So prüfen Sie, ob ein Git-Tag auf einen bestimmten Commit verweist"}} git/log -.-> lab-560115{{"So prüfen Sie, ob ein Git-Tag auf einen bestimmten Commit verweist"}} git/tag -.-> lab-560115{{"So prüfen Sie, ob ein Git-Tag auf einen bestimmten Commit verweist"}} end

Ausführen von git rev-parse für ein Tag

In diesem Schritt lernen wir, wie man den Befehl git rev-parse verwendet, um den Commit-Hash (Bestandsnummer des Commits) zu finden, der einem bestimmten Tag zugeordnet ist. Tags in Git sind wie permanente Markierungen in Ihrer Zeitlinie und werden normalerweise verwendet, um Release-Punkte zu markieren (z. B. v1.0, v2.0 usw.).

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 erstellen wir eine einfache Datei und machen einen Commit. So haben wir etwas, das wir taggen können.

echo "This is the first version." > version.txt
git add version.txt
git commit -m "Add initial version file"

Nach dem Commit sollten Sie eine Ausgabe ähnlich dieser sehen:

[master <commit-hash>] Add initial version file
 1 file changed, 1 insertion(+)
 create mode 100644 version.txt

Jetzt erstellen wir ein Tag für diesen Commit. Wir nennen es v1.0.

git tag v1.0

Dieser Befehl erzeugt keine Ausgabe, aber er hat ein einfaches (lightweight) Tag namens v1.0 erstellt, das auf den aktuellen Commit zeigt.

Um die Tags in Ihrem Repository anzuzeigen, können Sie git tag verwenden:

git tag

Sie sollten sehen:

v1.0

Jetzt verwenden wir git rev-parse, um den Commit-Hash zu finden, auf den das v1.0-Tag zeigt.

git rev-parse v1.0

Dieser Befehl gibt den vollständigen Commit-Hash aus:

<full-commit-hash>

Der Befehl git rev-parse ist sehr nützlich, um verschiedene Git-Referenzen (wie Tags, Branches oder sogar partielle Commit-Hashes) in ihren vollständigen Commit-Hash umzuwandeln. Dies ist hilfreich, wenn Sie die genaue Kennung eines Commits für Skripte oder andere Git-Operationen benötigen.

Vergleich mit dem Commit-Hash

Im vorherigen Schritt haben wir git rev-parse v1.0 verwendet, um den Commit-Hash (Bestandsnummer des Commits) zu erhalten, der dem v1.0-Tag zugeordnet ist. Jetzt vergleichen wir diesen Hash mit dem tatsächlichen Commit-Hash aus dem Git-Log, um sicherzustellen, dass sie übereinstimmen.

Zunächst stellen Sie sicher, dass Sie sich immer noch im Verzeichnis ~/project/my-time-machine befinden.

cd ~/project/my-time-machine

Jetzt betrachten wir das Commit-Log mit git log --oneline. Die Option --oneline zeigt jeden Commit in einer einzigen Zeile an, was hilfreich ist, um schnell die Commit-Historie und die kurzen Hashes zu sehen.

git log --oneline

Sie sollten eine Ausgabe ähnlich dieser sehen:

<short-commit-hash> (HEAD -> master, tag: v1.0) Add initial version file

Beachten Sie den kurzen Commit-Hash am Anfang der Zeile. Dies ist die abgekürzte Version des vollständigen Commit-Hashes. Sie können auch sehen, dass das v1.0-Tag neben diesem Commit aufgeführt ist, was darauf hinweist, dass das Tag auf diesen bestimmten Commit zeigt.

Jetzt holen wir erneut den vollständigen Commit-Hash mit git rev-parse v1.0:

git rev-parse v1.0

Dies gibt den vollständigen Commit-Hash aus:

<full-commit-hash>

Vergleichen Sie den vollständigen Commit-Hash von git rev-parse mit dem kurzen Commit-Hash von git log --oneline. Der kurze Hash besteht nur aus den ersten paar Zeichen des vollständigen Hashes. Beide beziehen sich auf denselben Commit.

Dieser Vergleich zeigt, dass git rev-parse <tag-name> erfolgreich den Commit-Hash abruft, auf den das angegebene Tag zeigt. Dies ist ein grundlegendes Konzept in Git: Tags sind einfach Zeiger auf bestimmte Commits. Das Verständnis dieser Beziehung ist der Schlüssel, um effektiv durch die Historie Ihres Projekts zu navigieren.

Testen verschiedener Tags

In diesem Schritt werden wir einen weiteren Commit und ein weiteres Tag erstellen, um die Verwendung von git rev-parse mit verschiedenen Tags weiter zu üben. Dies wird Ihr Verständnis dafür verstärken, wie Tags auf bestimmte Commits in der Historie Ihres Projekts verweisen.

Stellen Sie zunächst sicher, dass Sie sich im Verzeichnis ~/project/my-time-machine befinden.

cd ~/project/my-time-machine

Jetzt ändern wir die Datei version.txt und erstellen einen neuen Commit.

echo "This is the second version." >> version.txt
git add version.txt
git commit -m "Update version file to v2"

Nach dem Commit sollten Sie eine Ausgabe ähnlich dieser sehen:

[master <new-commit-hash>] Update version file to v2
 1 file changed, 1 insertion(+)

Wir haben nun einen neuen Commit erstellt. Fügen wir ein weiteres Tag, v2.0, zu diesem neuesten Commit hinzu.

git tag v2.0

Wiederum erzeugt dieser Befehl keine Ausgabe, aber das Tag wird erstellt.

Jetzt listen wir alle Tags in unserem Repository auf:

git tag

Sie sollten beide Tags sehen:

v1.0
v2.0

Schließlich verwenden wir git rev-parse, um den Commit-Hash für das neue Tag v2.0 zu erhalten.

git rev-parse v2.0

Dies gibt den vollständigen Commit-Hash für den Commit aus, in dem Sie das v2.0-Tag erstellt haben:

<full-commit-hash-for-v2>

Sie können auch git rev-parse verwenden, um erneut den Hash für das v1.0-Tag zu erhalten, um zu sehen, dass es immer noch auf den ursprünglichen Commit zeigt:

git rev-parse v1.0

Dies gibt den vollständigen Commit-Hash für den Commit aus, in dem Sie das v1.0-Tag erstellt haben (derselbe Hash, den Sie in Schritt 1 gesehen haben):

<full-commit-hash-for-v1>

Durch die Verwendung von git rev-parse mit verschiedenen Tag-Namen können Sie leicht den spezifischen Commit-Hash abrufen, der jeder getaggten Version Ihres Projekts zugeordnet ist. Dies ist unglaublich nützlich, um durch die Historie Ihres Projekts zu navigieren und auf bestimmte Release-Punkte zu verweisen.

Zusammenfassung

In diesem Lab haben wir gelernt, wie man prüft, ob ein Git-Tag (Markierung) auf einen bestimmten Commit (Versionspunkt) verweist. Wir haben begonnen, indem wir den Befehl git rev-parse <tag> verwendet haben, um den Commit-Hash (Versionsnummer) abzurufen, der einem bestimmten Tag zugeordnet ist. Dieser Befehl ist ein leistungsstarkes Werkzeug, um verschiedene Git-Referenzen in ihre vollständigen Commit-Hashes umzuwandeln.

Anschließend haben wir den Commit-Hash, der mit git rev-parse abgerufen wurde, mit dem tatsächlichen Commit-Hash aus dem Git-Log verglichen, um zu überprüfen, dass das Tag tatsächlich auf den erwarteten Commit verweist. Dieser Prozess ermöglicht es uns, den genauen Commit festzustellen, den ein Tag repräsentiert. Dies ist von entscheidender Bedeutung für die Verwaltung von Releases und das Nachverfolgen bestimmter Punkte in der Projektgeschichte.