So überprüfen Sie, ob ein Git-Commit Teil eines Tags ist

Einführung

In diesem Lab lernen Sie, wie Sie feststellen können, ob ein bestimmter Git-Commit in einem der Tags Ihres Projekts enthalten ist. Dies ist eine wertvolle Fähigkeit, um zu verstehen, welche Releases oder Versionen bestimmte Änderungen enthalten.

Durch praktische Übungen werden Sie den Befehl git tag --contains nutzen, um die Tags zu identifizieren, die mit einem bestimmten Commit verknüpft sind, und die Funktionalität von git describe zur Überprüfung von Tags erkunden. Sie werden diese Methoden auch mit ungetaggten Commits testen, um Ihr Verständnis zu festigen.

Skills Graph

Ausführen von git tag --contains Commit

In diesem Schritt lernen wir, wie man den Befehl git tag --contains verwendet, um herauszufinden, welche Tags einen bestimmten Commit enthalten. Dies ist nützlich, wenn Sie wissen möchten, welche Releases oder Versionen Ihres Projekts eine bestimmte Änderung enthalten.

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

cd ~/project/my-time-machine

Jetzt erstellen wir ein paar Commits und Tags, mit denen wir arbeiten können. Wir fügen eine neue Datei hinzu und erstellen einen Commit:

echo "Another message for the future" > message2.txt
git add message2.txt
git commit -m "Add a second message"

Sie sollten eine Ausgabe ähnlich der folgenden sehen:

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

Jetzt fügen wir diesem Commit ein Tag hinzu. Wir nennen es v1.0:

git tag v1.0

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

Erstellen wir nun einen weiteren Commit ohne Tag:

echo "A third message" > message3.txt
git add message3.txt
git commit -m "Add a third message"

Sie sollten eine Ausgabe ähnlich der folgenden sehen:

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

Jetzt haben wir zwei Commits und ein Tag. Verwenden wir git log --oneline, um unseren Commit-Verlauf anzuzeigen:

git log --oneline

Sie sollten etwas wie Folgendes sehen (die Commit-Hashes werden unterschiedlich sein):

<commit-hash> (HEAD -> master) Add a third message
<commit-hash> (tag: v1.0) Add a second message
<commit-hash> Send a message to the future

Beachten Sie, dass das v1.0-Tag mit dem Commit "Add a second message" verknüpft ist.

Jetzt finden wir heraus, welche Tags den Commit "Add a second message" enthalten. Dafür benötigen wir den Commit-Hash. Kopieren Sie aus der Ausgabe von git log --oneline den Commit-Hash neben (tag: v1.0).

Ersetzen Sie <commit-hash> durch den tatsächlich kopierten Hash und führen Sie den folgenden Befehl aus:

git tag --contains <commit-hash>

Sie sollten v1.0 in der Ausgabe sehen, da dieses Tag direkt auf diesen Commit zeigt.

Jetzt versuchen wir, herauszufinden, welche Tags den ersten Commit ("Send a message to the future") enthalten. Kopieren Sie den Commit-Hash für diesen Commit aus git log --oneline.

Ersetzen Sie <first-commit-hash> durch den tatsächlichen Hash und führen Sie aus:

git tag --contains <first-commit-hash>

Sie sollten immer noch v1.0 in der Ausgabe sehen. Dies liegt daran, dass v1.0 auf einem Commit liegt, der ein Nachfahren des ersten Commits ist. Die Option --contains prüft, ob der angegebene Commit ein Vorfahr des Commits ist, auf den das Tag zeigt.

Dieser Befehl ist sehr hilfreich, wenn Sie feststellen müssen, welche Versionen Ihrer Software einen bestimmten Bugfix oder eine bestimmte Funktion enthalten.

Verwenden von git describe zur Überprüfung von Tags

In diesem Schritt werden wir uns mit dem Befehl git describe befassen. Dieser Befehl wird verwendet, um das neueste Tag zu finden, das von einem Commit aus erreichbar ist. Er ist besonders nützlich, um menschenlesbare Namen für Commits zu generieren, insbesondere für solche, die nicht direkt getaggt sind.

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

Zunächst führen wir git describe ohne Argumente aus:

git describe

Da unser neuestes Commit nicht getaggt ist, sucht git describe nach dem nächsten Tag und gibt uns dann an, wie viele Commits seit diesem Tag gemacht wurden, und liefert eine kurze Version des Hashes des neuesten Commits. Sie sollten eine Ausgabe ähnlich der folgenden sehen:

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

Lassen Sie uns diese Ausgabe analysieren:

• v1.0: Dies ist das neueste Tag, das ein Vorfahr des aktuellen Commits ist.
• 1: Dies gibt an, dass es 1 Commit zwischen dem v1.0-Tag und dem aktuellen Commit gibt.
• g<commit-hash>: Das g steht für "git" und <commit-hash> ist ein kurzer, eindeutiger Bezeichner für den aktuellen Commit.

Dieses Format ist sehr nützlich, um bestimmte Builds oder Versionen Ihres Projekts zu identifizieren, auch wenn sie nicht genau einem Tag entsprechen.

Jetzt versuchen wir, git describe auf den Commit anzuwenden, der das v1.0-Tag hat. Wir benötigen den Commit-Hash für den Commit "Add a second message". Sie können diesen aus git log --oneline erhalten.

Ersetzen Sie <commit-hash-of-v1.0> durch den tatsächlichen Hash und führen Sie aus:

git describe <commit-hash-of-v1.0>

Diesmal sollte die Ausgabe einfach v1.0 sein:

v1.0

Dies liegt daran, dass der angegebene Commit direkt mit v1.0 getaggt ist. Wenn der Commit selbst getaggt ist, gibt git describe einfach den Namen des Tags aus.

Der Befehl git describe ist ein leistungsstarkes Werkzeug, um die Beziehung zwischen Ihren Commits und Ihren Tags zu verstehen und bietet eine kompakte Möglichkeit, Commits basierend auf ihrer Nähe zum nächsten Tag zu benennen.

Testen von ungetaggten Commits

In diesem Schritt werden wir weiter untersuchen, wie sich git describe bei Commits verhält, die nicht direkt getaggt sind. Dies wird Ihr Verständnis dafür verstärken, wie es das nächste Tag findet.

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

Wir haben derzeit einen Commit nach dem v1.0-Tag. Lassen Sie uns einen weiteren Commit erstellen:

echo "Yet another message" > message4.txt
git add message4.txt
git commit -m "Add a fourth message"

Sie sollten eine Ausgabe ähnlich der folgenden sehen:

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

Jetzt führen wir git describe erneut aus:

git describe

Diesmal sollte die Ausgabe ähnlich der folgenden sein:

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

Beachten Sie, dass die Zahl zwischen v1.0 und dem Commit-Hash jetzt 2 ist. Dies liegt daran, dass es seit der Erstellung des v1.0-Tags jetzt zwei Commits auf der master-Branch gibt. git describe zählt korrekt die Anzahl der Commits vom getaggten Commit bis zum aktuellen Commit.

Dieses Verhalten ist in Continuous-Integration- und Continuous-Deployment-Pipelines (CI/CD-Pipelines) sehr nützlich, wo Sie möglicherweise automatisch Versionsnamen für Builds basierend auf dem neuesten Tag und der Anzahl der Commits seit diesem Tag generieren möchten.

Lassen Sie uns noch etwas ausprobieren. Wir erstellen eine neue Branch und machen einen Commit auf dieser Branch.

git checkout -b feature/new-feature
echo "Feature file" > feature.txt
git add feature.txt
git commit -m "Add feature file"

Sie sollten eine Ausgabe ähnlich der folgenden sehen:

Switched to a new branch 'feature/new-feature'
[feature/new-feature <commit-hash>] Add feature file
 1 file changed, 1 insertion(+)
 create mode 100644 feature.txt

Jetzt führen Sie git describe auf dieser neuen Branch aus:

git describe

Die Ausgabe sollte immer noch auf dem v1.0-Tag basieren, aber die Commit-Zahl und der Hash werden unterschiedlich sein:

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

Obwohl wir sich auf einer anderen Branch befinden, findet git describe immer noch das nächste erreichbare Tag, das in diesem Fall v1.0 ist. Die Commit-Zahl 3 spiegelt die Anzahl der Commits vom v1.0-Tag bis zum aktuellen Commit auf der feature/new-feature-Branch wider (die zwei Commits auf der master-Branch plus der eine auf der Feature-Branch).

Dies zeigt, wie git describe über Branches hinweg funktioniert und immer das nächste Tag im Commit-Verlauf findet.

Zusammenfassung

In diesem Lab haben wir gelernt, wie man überprüft, ob ein Git-Commit Teil eines Tags ist, indem wir zwei Hauptmethoden verwendet haben. Zunächst haben wir uns mit dem Befehl git tag --contains <commit-hash> beschäftigt, der direkt alle Tags auflistet, die den angegebenen Commit enthalten. Dies ist besonders nützlich, um zu ermitteln, welche Releases oder Versionen eine bestimmte Änderung enthalten. Wir haben dies geübt, indem wir Commits und Tags erstellt, dann git log --oneline verwendet haben, um Commit-Hashes zu erhalten und anschließend mit git tag --contains abgefragt haben.

Zweitens haben wir kurz darauf eingegangen, git describe als eine weitere Möglichkeit zu nutzen, um Commits mit Tags in Verbindung zu bringen, obwohl die detaillierten Schritte hierfür im Auszug nicht vollständig angegeben wurden. Das Lab umfasste auch einen Schritt, um ungetaggte Commits zu testen, was das Verständnis dafür verstärkt, wie diese Befehle funktionieren, wenn ein Commit keinem Tag zugeordnet ist. Insgesamt hat das Lab praktische Erfahrungen in der Verwendung von Git-Befehlen vermittelt, um die Beziehung zwischen Commits und Tags in der Projektgeschichte zu verstehen und zu navigieren.