Montrez sur quel tag git vous vous trouvez?


216

J'ai du mal à savoir quelle balise est actuellement extraite.

Quand je fais:

git checkout tag1
git branch

Je n'arrive pas à savoir sur quelle balise je suis. Il enregistre uniquement:

* (no branch)
master

Est-il possible de savoir quelles balises sont extraites? Dans l'exemple ci-dessus, ce serait tag1.

Réponses:


326

Edit : Jakub Narębski a plus de git-fu. La commande beaucoup plus simple suivante fonctionne parfaitement:

git describe --tags

(Ou sans le --tags si vous avez extrait une balise annotée. Ma balise est légère, j'ai donc besoin des --tags.)

la réponse originale suit:

git describe --exact-match --tags $(git log -n1 --pretty='%h')

Quelqu'un avec plus de git-fu peut avoir une solution plus élégante ...

Cela tire parti du fait que git-logle journal est généré à partir de ce que vous avez extrait. %himprime le hachage abrégé. Trouve ensuite git describe --exact-match --tagsla balise (légère ou annotée) qui correspond exactement à cette validation.

La $()syntaxe ci-dessus suppose que vous utilisez bash ou similaire.


22
Une simple utilisation git describeafficherait le nom de la balise si vous êtes exactement sur la balise (annotée), ou <tag>-<n>-g<shortened sha-1>sinon, où <n>est le nombre de validations depuis <tag>.
Jakub Narębski

1
@Jakub - Merci. J'ai ajouté --exact-matchà ma réponse quelques secondes avant votre commentaire. C'est bien de savoir que vous pouvez le supprimer et toujours obtenir de bonnes informations à partir d'une entrée plus floue.
bstpierre

Merci, c'était exactement ce que je cherchais. Btw, même git-describe --exact-match (sans --tags) fonctionne pour moi.
grm

3
L'utilisation git rev-parse HEADest une meilleure solution que git log -n1 --pretty='%h'... mais pourquoi vous ne pouvez pas simplement écrire HEAD(ou rien, par git describedéfaut sur HEAD)?
Jakub Narębski

seul Guybrush déteste la porcelaine
vdegenne

71

Cela a fonctionné pour moi git describe --tags --abbrev=0


2
Oui. cela fonctionne même si vous n'êtes pas exactement sur cette balise! :)
Martin Muzatko

13
Uhhh. ... Si vous extrayez le hachage trois validations après la balise, vous n'êtes pas "sur cette balise". Il vous indique la dernière balise avant ou lors de la validation qui a été extraite. C'est donc incorrect.
ingyhere

Fonctionne aussi sur Windows :)
cowlinator

51

Afficher toutes les balises sur HEAD actuel (ou commit)

git tag --points-at HEAD

1
Notez que cette commande ne signale pas d'erreur sur la ligne de commande même si le résultat est vide. Punaise? Il renvoie également une liste s'il existe plusieurs balises à cet emplacement. C'est la meilleure réponse, mais les scripteurs doivent procéder avec prudence en gardant ces avertissements à l'esprit.
ingyhere

Suite au commentaire de @ ingyhere. Oui, c'est une bonne information qu'il n'a pas d'erreur, et les gens doivent gérer le résultat en conséquence. Mais je n'appellerais pas ça un bug. Pour mon cas, «vide si aucune balise» est valide. Dans d'autres cas, quelqu'un peut l'enregistrer dans une variable puis vérifier s'il est vide (lien vers les instructions bash)
driftcatcher

23

git describeest une porcelaine commande en , que vous devez éviter:

http://git-blame.blogspot.com/2013/06/checking-current-branch-programately.html

Au lieu de cela, j'ai utilisé:

git name-rev --tags --name-only $(git rev-parse HEAD)

11
Il revient "indéfini"
Stranger

4
Cela génère un suivi ^0pour les validations qui correspondent aux balises (par exemple, pour la balise 1.0qu'il génère 1.0^0). Existe-t-il un moyen d'avoir uniquement une sortie Git 1.0, ou dois-je utiliser sed pour cela?
Daniel Serodio

13
Juste une petite pioche conceptuelle: je pense que vous avez inversé le sens de la porcelaine et de la plomberie. Il est correct d'utiliser de la porcelaine, c'est de haut niveau et destiné à un usage normal . La plomberie est interne (comme son nom l'indique) et n'est pas recommandée car les développeurs de git se réservent le droit de modifier leurs arguments et leurs résultats sans avertissement. Votre première suggestion est donc en fait la plus appropriée.
Leo Antunes

5
L'article lié dit d'éviter d'utiliser "git branch" car cela ne fonctionne pas pour ce cas d'utilisation. Je ne vois aucune bonne raison pour éviter d'utiliser git describe. Comme le dit Leo, les commandes "Porcelaine" sont les commandes que vous êtes généralement censé utiliser. Évitez les commandes de plomberie à moins que vous ne sachiez vraiment ce que vous faites. "git describe" fonctionne très bien.
Danny

4
Les commandes "Porcelaine" sont celles que vous devez utiliser, pas celles que vous devez éviter. Ce sont les commandes dont la sortie est lisible par machine et ne changera pas dans les futures versions, elles peuvent donc être utilisées dans les scripts, etc. lisibles, non pas parce que quelque chose d'important a réellement changé.
rjmunro

22

Lorsque vous extrayez une étiquette, vous avez ce qu'on appelle une "tête détachée" . Normalement, la validation HEAD de Git est un pointeur vers la branche que vous avez actuellement extraite. Cependant, si vous extrayez autre chose qu'une branche locale (une balise ou une branche distante, par exemple), vous avez une "tête détachée" - vous n'êtes pas vraiment sur une branche. Vous ne devriez pas faire de commits lorsque vous êtes sur une tête détachée.

Vous pouvez vérifier une balise si vous ne souhaitez pas apporter de modifications. Si vous examinez simplement le contenu des fichiers ou si vous souhaitez créer votre projet à partir d'une balise, vous pouvez utiliser git checkout my_taget travailler avec les fichiers, vous pouvez utiliser tant que vous n'effectuez aucune validation . Si vous souhaitez commencer à modifier des fichiers, vous devez créer une branche basée sur la balise:

$ git checkout -b my_tag_branch my_tag

va créer une nouvelle branche appelée à my_tag_branchpartir de my_tag. Vous pouvez valider des modifications sur cette branche.


1
Réponse fantastique.
Panos Filianos

9

git log --decorate

Cela vous indiquera quelles références pointent vers le commit actuellement extrait.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.