Comment obtenir le dernier nom d'étiquette dans la branche courante de Git?

pour obtenir l'étiquette la plus récente:

git describe --tags

pour obtenir le plus récent annoté étiquette:

git describe --abbrev=0 --tags

affichera l'étiquette de la dernière propagation étiquetée sur toutes les branches

git describe --tags $(git rev-list --tags --max-count=1)

pour obtenir l'étiquette la plus récente, vous pouvez faire:

$ git for-each-ref refs/tags --sort=-taggerdate --format='%(refname)' --count=1

bien sûr, vous pouvez changer l'argument count ou le champ sort comme désiré. Il semble que vous dire de poser une question légèrement différente, mais cela ne veut répondre à la question que je l'interpréter.

et ça?

TAG=$(git describe $(git rev-list --tags --max-count=1))

techniquement, ne vous obtiendra pas nécessairement la dernière étiquette, mais le dernier commit qui est étiqueté, qui peut ou non être la chose que vous recherchez.

git describe --tags

renvoie la dernière étiquette visible par la branche courante

"le plus récent" pourrait avoir deux significations en termes de git.

vous pourriez dire, "quelle étiquette a la date de création la plus récente dans le temps", et la plupart des réponses ici sont pour cette question. En ce qui concerne votre question, vous voudriez retourner l'étiquette c .

ou" quelle étiquette est la plus proche dans l'histoire du développement d'une branche nommée", habituellement la branche sur laquelle vous êtes, HEAD . Dans votre question, ceci retournerait l'étiquette a .

ceux-ci pourraient être différents bien sûr:

A->B->C->D->E->F (HEAD)
       \     \
        \     X->Y->Z (v0.2)
         P->Q (v0.1)

imaginez le développeur étiqueté Z comme v0.2 le lundi, puis étiqueté Q comme v0.1 le mardi. v0.1 est le plus récent, mais v0.2 est plus proche de la tête dans l'histoire du développement, dans le sens où le chemin sur lequel il se trouve commence à un point plus proche de la tête.

je pense que vous voulez habituellement cette deuxième réponse, plus près dans le développement de l'histoire. Vous pouvez le découvrir en utilisant git log v0.2..HEAD etc pour chaque étiquette. Ceci vous donne le nombre de commits sur la tête puisque le chemin se terminant par v0.2 divergeait du chemin suivi par la tête.

voici un script Python qui fait cela en itérant toutes les balises qui exécutent cette vérification, puis en imprimant la balise avec le moins de commits sur la tête puisque le chemin de la balise divergeait:

https://github.com/MacPython/terryfy/blob/master/git-closest-tag

git describe fait quelque chose de légèrement différent, en ce qu'il suit de retour de (par exemple) tête pour trouver la première étiquette qui est sur un chemin de retour dans l'histoire de la tête. En termes de git, git describe cherche des étiquettes qui sont "accessibles" de la tête. Il ne trouvera donc pas des balises comme v0.2 qui ne sont pas sur le chemin du retour de HEAD, mais un chemin qui s'en est écarté.

git log --tags --no-walk --pretty="format:%d" | sed 2q | sed 's/[()]//g' | sed s/,[^,]*$// | sed  's ......  '

SI VOUS AVEZ BESOIN DE PLUS D'UNE DERNIÈRE ÉTIQUETTE

(git décrire --tags donne parfois mal de tables de hachage, je ne sais pas pourquoi, mais pour moi-max-comte 2 ne marche pas)

c'est ainsi que vous pouvez obtenir la liste avec les 2 derniers noms d'étiquette dans l'ordre chronologique inverse, fonctionne parfaitement sur git 1.8.4. Pour les versions précédentes de git (comme 1.7.* ), il n'y a pas de chaîne "tag:" en sortie-il suffit de supprimer le dernier appel sed

Si vous voulez plus de 2 dernières étiquettes - changez ce "sed 2q" en" sed 5q "ou ce que vous avez besoin

alors vous pouvez facilement analyser chaque nom d'étiquette à variable ou ainsi.

git tag -l ac* | tail -n1

obtenir la dernière étiquette avec le préfixe " ac . Par exemple , étiquette nommée avec ac1.0.0 , ou ac1.0.5 . Les autres étiquettes nommées 1.0.0 , 1.1.0 seront ignorées.

git tag -l [0-9].* | tail -n1

Obtenir la dernière balise, dont le premier caractère est 0-9 . Donc, ces étiquettes avec le premier caractère a-z seront ignorées.

plus d'information

git tag --help # Help for `git tag`

git tag -l <pattern>

Liste des étiquettes avec des noms qui correspondent au motif donné (ou, si aucune motif). L'exécution de "git tag" sans arguments contient aussi des listes toutes les balises. Le motif est un joker shell (i.e., assorti en utilisant fnmatch (3)). Plusieurs motifs peuvent être donnés; si l'un d'eux les matchs, le tag est affiché.

tail -n <number> # display the last part of a file
tail -n1 # Display the last item 

mise à Jour

Avec git tag --help , à propos de la sort argument. Il utilisera lexicorgraphic order par défaut, si la propriété tag.sort n'existe pas.

ordre de tri par défaut, la valeur configurée pour la balise.tri variable si elle existe, ou ordre lexicographique autrement. Voir git-config(1).

D'après google, quelqu'un a dit git 2.8.0 support suivant la syntaxe.

git tag --sort=committerdate

git describe --abbrev=0 --tags

si vous ne voyez pas la dernière étiquette, assurez-vous de vérifier l'origine avant de lancer que:

git remote update

Ce qui est mauvais avec toutes les suggestions (à l'exception de Matthieu Brett explication, jusqu'à la date de cette réponse post)?

juste exécuter n'importe quelle commande fournie par l'autre sur l'histoire de git jQuery quand vous à point différent de l'histoire et vérifier le résultat avec marquage visuel de la représentation de l'histoire (i did c'est pourquoi vous voyez ce post):

$ git log --graph --all --decorate --oneline --simplify-by-decoration

de nos jours, de nombreux projets réalisent des versions (et donc le marquage) dans une branche séparée de la ligne principale .

Il y a bonne raison pour cela. Il suffit de regarder à tous les projets JS/CSS bien établis. Pour les conventions d'utilisateur, ils transportent des fichiers de publication binaires/abrégés dans les DVCS. Naturellement, en tant que responsable de projet, vous ne voulez pas jeter votre ligne principale diff histoire avec inutile les blobs binaires et effectuer la validation de construire des artefacts principale .

parce que Git utilise DAG et non histoire linéaire - il est difficile de définir la distance métrique donc nous pouvons dire-oh que rev est le plus proche de mon HEAD !

je commence mon propre voyage dans (regardez à l'intérieur, je n'ai pas copié des images de preuve de fantaisie à ce long post):

Quelle est l'étiquette la plus proche dans le passé en ce qui concerne la ramification en Git?

actuellement, j'ai 4 définition raisonnable de la distance entre l'étiquette et la révision avec diminution de l'utilité:

• longueur du chemin le plus court à partir de HEAD à fusion "de base 1519190920" tag
• date de fusion "de base 1519190920" entre HEAD et tag
• nombre de tours qui sont accessibles à partir de la tête mais non à partir de l'étiquette
• date de la balise quel que soit fusion "de base 1519190920"

$ git tag \
     | while read t; do \
         b=`git merge-base HEAD $t`; \
         echo `git log -n 1 $b --format=%ai` $t; \
       done | sort

$ git tag \
    | while read t; do echo `git rev-list --count $t..HEAD` $t; done \
    | sort -n

$ git log --tags --simplify-by-decoration --pretty="format:%ci %d" | sort -r

$ git log --max-count=1