In den folgenden Zeilen:
$ git tag -n1
v1.8 Tagged the day before yesterday
v1.9 Tagged yesterday
v2.0 Tagged today
$ git describe
v1.9-500-ga6a8c67
$
Kann jemand erklären, warum das v2.0-Tag nicht von "git description" verwendet wird und wie dies behoben werden kann? Das v2.0-Tag ist bereits gepusht, daher kann ich es wohl nicht einfach löschen und erneut hinzufügen.
Antworten:
git describeVerwendet standardmäßig nur kommentierte Tags. Geben Sie die --tagsOption an, damit auch Lightweight-Tags verwendet werden.
Stellen Sie sicher, dass Sie das richtige Commit ( git rev-parse HEAD) ausgecheckt haben . Kommentierte Tags werden mit erstellt git tag -a. Wenn Sie dies tun git show <tagname>und nur das Commit sehen, handelt es sich um ein leichtes Tag. Wenn Sie eine zusätzliche Tag-Nachricht sehen, handelt es sich um ein mit Anmerkungen versehenes Tag.
--all, alle Refs zu verwenden. wird HEAD durch das Tag beschrieben? (nur um sicher zu gehen)
HEADist das aktuell ausgecheckte Commit.
git rev-parse HEAD) ausgecheckt haben. Stellen Sie außerdem sicher, dass Sie die neueste Version von git verwenden. Kommentierte Tags werden mit erstellt git tag -a. Wenn Sie dies tun git show <tagname>und das Commit sehen, handelt es sich um ein leichtes Tag. Wenn Sie eine Tag-Nachricht sehen, handelt es sich um ein mit Anmerkungen versehenes Tag.
Als uns dies passiert ist, wurden zwei Tags für dasselbe Commit angewendet. Ob dies der Fall ist, können Sie durch Ausführen feststellen
# git log --oneline --decorate=short
deba4b4 (tag: v1.1.0.20.0, tag: v1.1.0.19.0) 001 New buildnumber
Hier gibt es zwei Tags, eines für Version 19 und eines für 20. 20 wurde nach 19 markiert, jedoch für dasselbe Commit. In diesem Fall beschreiben zurückgegeben
# git describe --tags
v1.1.0.19.0
Ich weiß nicht, warum es das getan hat, aber so scheint es mit doppelten Tags zu funktionieren.
Ein anderer Fall, in dem dies passieren kann, ist, wenn Sie ein Tag in einem Zweig haben, das Ihnen "näher" ist. Dieser Fall wurde in diesem Blogbeitrag erklärt .
Das Problem besteht darin git tag, dass alle Tags in allen Zweigen angezeigt werden, während git describenur Tags für Commits verwendet werden, die im aktuellen Zweig verfügbar sind .
Hier ist ein Beispiel (der Grund, warum ich tatsächlich hierher gekommen bin):
$ git tag | tail -n3
v0.4.0
v0.4.1
v0.4.2
Es zeigt das neueste verfügbare Tag v0.4.2, aber dies ist meine Ausgabe von git describe:
$ git describe --tags
v0.4.0-2-acd334c
Ich bin auf Entwicklungszweig. Wenn ich in das Protokoll grabe, sehe ich tatsächlich, dass die neuesten Tags im aktuellen Zweig nicht verfügbar sind:
$ git log --oneline --decorate=short | grep 'tag\:' | head -n3
acd334c (tag: v0.4.0) Merge pull request #1061
988fe5e (tag: v0.3.6) Merge pull request #859
5f97274 (tag: v0.3.5) Merge pull request #646
In meinem Fall haben die Entwickler beschlossen, einen neuen Release- Zweig ausschließlich zum Markieren von Releases zu erstellen, was dazu führt, dass der Entwicklungszweig nicht mehr mit den Tags auf dem neuesten Stand ist.
Hoffe das hilft und danke @eis für die Idee beim Überprüfen der Protokolle.
In Ihrem Beispiel v1.9handelt es sich höchstwahrscheinlich um ein Tag aus Merge Commit.
Standardmäßig wird Git-Verhalten erwartet, und Sie können hier mehr darüber lesen: https://git.kernel.org/pub/scm/git/git.git/commit/?id=80dbae03
Um Zusammenführungs-Tags zu ignorieren, wenn Sie nach den neuesten im aktuellen Zweig suchen, können Sie die --first-parentOption verwenden.
git describe --tags --first-parent --abbrev=0
- Erster Elternteil
Befolgen Sie nur das erste übergeordnete Commit, wenn ein Merge-Commit angezeigt wird. Dies ist nützlich, wenn Sie keine Tags für Zweige abgleichen möchten, die im Verlauf des Ziel-Commits zusammengeführt wurden.