So prüfen Sie, ob ein Git-Tag das neueste ist

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) das neueste ist. Wir werden verschiedene Methoden untersuchen, um das neueste Tag in Ihrem Repository zu bestimmen.

Sie beginnen damit, den Befehl git describe --tags zu verwenden, um das neueste erreichbare Tag zu finden und das Ausgabeformat zu verstehen. Dann lernen Sie, wie Sie Tags nach Version sortiert auflisten können, indem Sie git tag --sort=-v:refname verwenden, um das neueste Tag leicht zu identifizieren. Abschließend üben Sie das Testen älterer Tags, um Ihr Verständnis davon zu festigen, wie Git die Tag-Geschichte verwaltet.


Skills Graph

%%%%{init: {'theme':'neutral'}}%%%% flowchart RL git(("Git")) -.-> git/BasicOperationsGroup(["Basic Operations"]) git(("Git")) -.-> git/BranchManagementGroup(["Branch Management"]) git/BasicOperationsGroup -.-> git/add("Stage Files") git/BasicOperationsGroup -.-> git/commit("Create Commit") git/BranchManagementGroup -.-> git/checkout("Switch Branches") git/BranchManagementGroup -.-> git/tag("Git Tags") subgraph Lab Skills git/add -.-> lab-560113{{"So prüfen Sie, ob ein Git-Tag das neueste ist"}} git/commit -.-> lab-560113{{"So prüfen Sie, ob ein Git-Tag das neueste ist"}} git/checkout -.-> lab-560113{{"So prüfen Sie, ob ein Git-Tag das neueste ist"}} git/tag -.-> lab-560113{{"So prüfen Sie, ob ein Git-Tag das neueste ist"}} end

Führen Sie git describe --tags aus

In diesem Schritt lernen wir, wie man den Befehl git describe --tags verwendet. Dieser Befehl ist sehr nützlich, um das neueste Tag (Markierung) zu finden, das von einem Commit aus erreichbar ist. Er wird oft verwendet, um Commits auf eine menschenlesbare Weise zu benennen, insbesondere für Releases.

Zunächst stellen wir sicher, dass wir uns in unserem Projektverzeichnis befinden. Öffnen Sie Ihr Terminal und geben Sie ein:

cd ~/project/my-time-machine

Jetzt erstellen wir ein paar Commits und Tags, um git describe --tags zu demonstrieren. Wir fügen eine neue Datei hinzu und erstellen einen Commit:

echo "This is the second message." > message2.txt
git add message2.txt
git commit -m "Add second message file"

Sie sollten eine Ausgabe ähnlich dieser sehen:

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

Jetzt fügen wir diesem Commit ein Tag hinzu. Tags sind wie permanente Labels für bestimmte Punkte in der Projektgeschichte. Wir erstellen ein einfaches (lightweight) Tag namens v1.0:

git tag v1.0

Dieser Befehl erzeugt keine Ausgabe, aber er hat ein Tag erstellt, das auf unseren neuesten Commit zeigt.

Erstellen wir einen weiteren Commit:

echo "This is the third message." > message3.txt
git add message3.txt
git commit -m "Add third message file"

Sie sollten eine Ausgabe ähnlich dieser sehen:

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

Jetzt führen wir git describe --tags aus:

git describe --tags

Sie sollten eine Ausgabe ähnlich dieser sehen:

v1.0-1-g<commit-hash>

Lassen Sie uns diese Ausgabe analysieren:

  • v1.0: Dies ist der Name des neuesten Tags (v1.0), das von dem aktuellen Commit aus erreichbar ist.
  • 1: Diese Zahl gibt an, wie viele Commits seit dem v1.0-Tag gemacht wurden.
  • g<commit-hash>: Das g steht für "git", und die folgenden Zeichen sind eine Kurzform des Commit-Hashes. Dies hilft, den Commit eindeutig zu identifizieren.

Somit sagt uns v1.0-1-g<commit-hash>, dass der aktuelle Commit einen Commit von dem v1.0-Tag entfernt ist.

Das Verständnis von git describe --tags ist hilfreich, um schnell zu erkennen, wo man sich in der Projektgeschichte relativ zu den Tags befindet. Es ist besonders nützlich in automatisierten Build-Prozessen, um Versionsnamen zu generieren.

Verwenden Sie git tag --sort=-v:refname

In diesem Schritt lernen wir, wie man die Tags (Markierungen) in einer bestimmten Reihenfolge auflisten kann, indem man den Befehl git tag --sort verwendet. Dies ist hilfreich, wenn Sie viele Tags haben und sie in einer logischen Reihenfolge, beispielsweise nach Versionsnummer, anzeigen möchten.

Zunächst stellen wir sicher, dass wir uns in unserem Projektverzeichnis befinden:

cd ~/project/my-time-machine

Wir haben bereits ein Tag, v1.0. Fügen wir noch ein paar Tags hinzu, um zu sehen, wie die Sortierung funktioniert. Wir fügen ein Tag für den ersten Commit (wo wir message.txt erstellt haben) hinzu. Dazu benötigen wir den Commit-Hash des ersten Commits. Sie können ihn mit git log --oneline finden:

git log --oneline

Suchen Sie nach der ersten Commit-Nachricht "Send a message to the future" und kopieren Sie den kurzen Commit-Hash daneben. Er sieht etwa so aus: a1b2c3d.

Jetzt erstellen wir ein Tag namens v0.9, das auf diesen ersten Commit zeigt. Ersetzen Sie <first-commit-hash> durch den tatsächlichen Hash, den Sie gefunden haben:

git tag v0.9 <first-commit-hash>

Fügen wir noch ein Tag, v1.1, für den aktuellen Commit hinzu:

git tag v1.1

Jetzt haben wir drei Tags: v0.9, v1.0 und v1.1. Wenn wir einfach git tag ausführen, werden sie möglicherweise nicht in Versionsreihenfolge angezeigt:

git tag

Die Ausgabe könnte etwa so aussehen (die Reihenfolge kann variieren):

v0.9
v1.0
v1.1

Um die Tags in Versionsreihenfolge aufzulisten, können wir git tag --sort=version verwenden. Die Option -v:refname ist eine gängige Methode, um Tags basierend auf ihrem Namen mithilfe einer versionsbewussten Sortierung zu sortieren. Das - vor -v:refname bedeutet, dass die Sortierung in absteigender Reihenfolge (neueste Version zuerst) erfolgen soll.

Probieren wir es aus:

git tag --sort=-v:refname

Sie sollten die Tags von der höchsten zur niedrigsten Version aufgelistet sehen:

v1.1
v1.0
v0.9

Diese Sortierung ist sehr nützlich, wenn Sie Releases verwalten und schnell die neuesten Versionen Ihres Projekts sehen möchten. Die --sort-Option ist leistungsstark und kann auch mit anderen Kriterien verwendet werden, aber das Sortieren nach Versionsname ist ein gängiger Anwendungsfall für Tags.

Ältere Tags testen

In diesem Schritt werden wir untersuchen, wie sich git describe --tags verhält, wenn wir nicht auf dem neuesten Commit sind. Dies zeigt, wie der Befehl Ihnen hilft, Ihre Position in der Projektgeschichte relativ zu Ihren Tags zu verstehen.

Zunächst stellen Sie sicher, dass Sie sich im Projektverzeichnis befinden:

cd ~/project/my-time-machine

Wir befinden uns derzeit auf dem neuesten Commit, der mit v1.1 getaggt ist. Lassen Sie uns git describe --tags erneut verwenden, um dies zu bestätigen:

git describe --tags

Die Ausgabe sollte v1.1 sein, da der aktuelle Commit genau dort ist, wo das v1.1-Tag zeigt.

Jetzt gehen wir zurück zum Commit, wo wir das v1.0-Tag erstellt haben. Wir können git checkout gefolgt vom Tag-Namen verwenden, um dies zu tun.

git checkout v1.0

Sie werden eine Ausgabe sehen, die darauf hinweist, dass Sie sich in einem 'detached HEAD'-Zustand befinden. Machen Sie sich darüber keine Sorgen; es bedeutet nur, dass Sie sich auf einen bestimmten Commit statt auf der Spitze eines Branches befinden.

Note: switching to 'v1.0'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command (for example,
'git switch -c <new-branch-name>'). Or, if you meant to switch to a number
of commits past an existing branch, what you probably want is to use
'git switch <branch-name>~<number>'.

Switched to a new branch 'v1.0'

Jetzt, da wir am Commit sind, der mit v1.0 getaggt ist, lassen Sie uns git describe --tags erneut ausführen:

git describe --tags

Die Ausgabe sollte einfach sein:

v1.0

Dies liegt daran, dass der aktuelle Commit genau dort ist, wo sich das v1.0-Tag befindet. Es gibt keine Commits zwischen der aktuellen Position und dem v1.0-Tag.

Lassen Sie uns versuchen, zurück zum Commit zu gehen, wo wir das v0.9-Tag erstellt haben:

git checkout v0.9

Wieder werden Sie die detached HEAD-Nachricht sehen.

Jetzt führen Sie git describe --tags aus:

git describe --tags

Die Ausgabe sollte ähnlich sein:

v0.9

Dies bestätigt, dass git describe --tags das nächste Tag von Ihrer aktuellen Position in der Commit-Historie korrekt identifiziert. Diese Fähigkeit, Commits relativ zu Tags zu beschreiben, ist sehr nützlich, um den Zustand Ihres Projekts zu verschiedenen Zeitpunkten zu verstehen.

Um zurück zum neuesten Commit auf dem master-Branch zu gelangen, können Sie verwenden:

git checkout master

Sie sollten eine Ausgabe sehen, die darauf hinweist, dass Sie zurück zum master-Branch gewechselt haben:

Switched to branch 'master'
Your branch is up to date with 'origin/master'.

Zusammenfassung

In diesem Lab haben wir gelernt, wie man mithilfe verschiedener Methoden prüft, ob ein Git-Tag (Markierung) das neueste ist. Wir haben zunächst den Befehl git describe --tags untersucht, der hilft, das neueste erreichbare Tag von einem Commit zu identifizieren und Informationen über die Anzahl der Commits seit diesem Tag sowie einen kurzen Commit-Hash liefert. Dieser Befehl ist nützlich, um die Beziehung zwischen dem aktuellen Commit und dem nächsten Tag zu verstehen.

Wir haben auch gelernt, wie man git tag --sort=-v:refname verwendet, um Tags in absteigender Reihenfolge basierend auf ihrer Versionsnummer aufzulisten. Dadurch können wir das neueste Tag anhand seines Namens leicht identifizieren. Schließlich haben wir untersucht, wie man ältere Tags testet, um zu verstehen, wie sich git describe --tags verhält, wenn man nicht auf dem neuesten Commit ist. Diese Techniken bieten wertvolle Werkzeuge für die Verwaltung und das Verständnis von Tags in einem Git-Repository.