Comment savoir à quel commit un tag pointe dans Git?


411

J'ai un tas de balises non annotées dans le référentiel et je veux déterminer à quel commit ils pointent. Existe-t-il une commande qui répertorie simplement les balises et leurs SHA de validation? Vérifier l'étiquette et regarder la tête me semble un peu trop pénible.

Mise à jour

J'ai réalisé après avoir parcouru les réponses que ce que je voulais réellement, c'était simplement regarder l'histoire menant au tag, ce qui git log <tagname>est suffisant.

La réponse marquée comme réponse est utile pour obtenir une liste de balises et de leurs validations, c'est ce que j'ai demandé. Avec un peu de piratage de shell, je suis sûr qu'il est possible de les transformer en message SHA + Commit.


3
Je veux souligner que git show-refmontre sha de la balise, pas sha de la révision du repo. $ git show-ref test 08b9c774ab20e5bdb638339cf4ea2c124b0dae54 refs / tags / test $ git checkout test HEAD est maintenant au c7f8831 ... $ git checkout 08b9c77 HEAD est maintenant au c7f8831 ...
Konstantin Pelepelin

si vos tags sont annotés, alors vous avez besoin de--dereference
Trevor Boyd Smith

Réponses:


348

Une façon de le faire serait de git rev-list. Les éléments suivants afficheront la validation vers laquelle pointe une balise:

$ git rev-list -n 1 $TAG

Vous pouvez l'ajouter comme alias ~/.gitconfigsi vous l'utilisez souvent:

[alias]
  tagcommit = rev-list -n 1

Et puis appelez-le avec:

$ git tagcommit $TAG

30
Pourquoi ne pas utiliser git rev-parse <tag>? Ou git rev-list -1 <tag>?
Jakub Narębski

52
@ Jakub: git rev-parse $TAGrenvoie le SHA1 de l'objet tag, pas le commit vers lequel il pointe. git rev-list -1fonctionne, cependant.
mipadi

11
@mipadi: Pour les balises non annotées, cela n'a pas d'importance; pour les balises annotées que vous pouvez utiliser git rev-parse $TAG^{commit}ou git rev-parse $TAG^{}pour déréférencer une balise annotée / signée
Jakub Narębski

5
Vous pouvez utiliser:git rev-list $TAG --max-count=1
b73

4
@RobinHsu: si vous avez des balises annotées , qui sont créées avec git tag -aou git tag -s, alors vous git rev-parse <tag>obtiendriez SHA-1 d'un objet de balise lui-même, tandis git rev-list -1 <tag>que donnerait SHA-1 de commit (révision) vers lequel il pointe, comme git rev-parse <tag>^{commit}. HTH.
Jakub Narębski

240
git show-ref --tags

Par exemple, git show-ref --abbrev=7 --tagsvous montrera quelque chose comme ceci:

f727215 refs/tags/v2.16.0
56072ac refs/tags/v2.17.0
b670805 refs/tags/v2.17.1
250ed01 refs/tags/v2.17.2

Merci pour cela, ce cache en fait la sémantique de regarder soit .git/packed-refsou.git/refs/tags/*
Igor Zevaka

3
hmmm. il a un comportement étrange dans mon référentiel: git tag -a v0.1.1-alpha a9dcc1f24cacde535523bddc22f4c69467428550; git show-ref - tags -> b784145a9a71478337f5ceae30aaac4e1b955ee5 refs / tags / v0.1.1-alpha; voir la réponse de Jakub Narebski
NickSoft

6
cela fonctionne, même si je me demande s'il ne serait pas logique de les git tag --verbosemontrer aussi?
non

34
Cela montrera la référence de la balise elle-même, pas la validation des points de balise. Vous devez ajouter l' -dindicateur pour obtenir le commit référencé (sur une deuxième ligne).
Old Pro

4
@CharlesBailey, assez bien, mais la question et les réponses se sont transformées pour inclure des balises annotées et le fait qu'il git show-refse comporte différemment sur les deux différents types de balises n'est pas une évidence ni une connaissance commune.
Old Pro

104

Utilisez simplement git show <tag>

Cependant, il sauvegarde également les différences de validation. Pour omettre ces différences, utilisez git log -1 <tag>. (Merci à @DolphinDream et @demisx!)


7
Sur SO, lorsqu'une question a de nombreuses réponses possibles différentes, les réponses qui sont publiées en premier sont votées en premier - les plaçant en haut de la liste, et les obtenant ainsi plus de votes plus tard. Il s'agit d'une boucle de rétroaction de polarisation basée sur la vitesse de réponse par rapport à la qualité de la réponse. Avec une imagination suffisante, ce problème pourrait être résolu.
samthebest

6
"Meilleure solution" pour quoi? Si l'intérêt est de trouver le SHA d'un commit, le tag pointe vers le "git show <mytag>" n'est PAS la meilleure solution. Cette commande affichera l'intégralité du diff introduit par la validation. Pour répertorier uniquement le SHA de la validation, la balise pointe vers "git rev-list <mytag> -n 1" est la bonne solution.
DolphinDream

Ce n'est pas la réponse à la question du PO. git show <tag>montre le diff, pas le commit auquel le tag pointe.
demisx

@demisx De quoi tu parles ?? Il montre définitivement le hachage de validation, ainsi que le tagueur, la date et d'autres informations. Essayez-le.
Hlung

4
@Hlung Comme l'a souligné @DolphinDream, vide git showbeaucoup plus de choses sur l'écran qui n'ont pas besoin d'être là. Il masque le hachage de validation réel que l'on recherche. Une meilleure commande est git log -1 [tag-name]ou git log -1 --pretty=oneline [tag-name]si vous voulez des oneliners.
demisx

40

Sur mon référentiel, git show-ref TAGaffiche le hachage de la balise, pas le hachage du commit vers lequel il pointe.

git show-ref --dereference TAG montre, en outre, le commit pointé.


34

Depuis Igor Zevaka :

Sommaire

Puisqu'il y a environ 4 réponses presque aussi acceptables mais différentes, je vais résumer toutes les différentes façons de skin un tag.

  1. git rev-list -1 $TAG( réponse ). git rev-listrenvoie les commits qui mènent à la $TAGmême chose git logmais ne montrant que le SHA1 du commit. Le -1limite la sortie au commit sur lequel il pointe.

  2. git show-ref --tags( réponse ) affichera toutes les balises (locales et récupérées à distance) et leurs SHA1.

  3. git show-ref $TAG( réponse ) affichera l'étiquette et son chemin avec le SHA1.

  4. git rev-parse $TAG( réponse ) affichera le SHA1 d'une balise non annotée.

  5. git rev-parse --verify $TAG^{commit}( réponse ) affichera un SHA1 de balises annotées et non annotées. Sous Windows git rev-parse --verify %TAG%^^^^{commit}(quatre chapeaux).

  6. cat .git/refs/tags/*ou cat .git/packed-refs( réponse ) selon que la balise est locale ou récupérée à distance.


33

Utilisation

git rev-parse --verify <tag>^{commit}

(qui retournerait SHA-1 d'un commit même pour une balise annotée).


git show-ref <tag>fonctionnerait également s'il <tag>n'est pas annoté. Et il y en a toujours git for-each-ref(voir la documentation pour les détails).


11
Je préfère git rev-parse <tag>~0ce qui semble également fonctionner, et ne nécessite aucun échappement spécial sur Windows (sur lequel quatre chapeaux (^) sont nécessaires au lieu d'un). Le suffixe ~<number>donne le <numéro> e commit parent, donc ~0le commit lui-même. Btw, ^0est également un raccourci valide pour le ^{commit}suffixe de révision.
Attila

15

Que dis-tu de ça:

git log -1 $TAGNAME

OU

git log -1 origin/$TAGNAME

10

Afin d'obtenir le sha / hachage du commit auquel une balise fait référence (pas le sha de la balise):

git rev-list -1 <tag>


8

J'aimerais aussi savoir la "bonne" façon, mais en attendant, vous pouvez le faire:

git show mytag | head -1    

Avec titre de commitgit show --oneline mytag | head -1
Stéphane

7

Même si c'est assez ancien, je pensais souligner une fonctionnalité intéressante que je viens de trouver pour répertorier les balises avec des commits:

git log --decorate=full

Il montrera les branches qui se terminent / démarrent lors d'une validation, et les balises pour les validations.


4

Vous pourriez également obtenir une image plus facile à interpréter de l'endroit où les balises pointent vers l'utilisation

git log --graph |git name-rev --stdin --tags |less

puis faites défiler jusqu'au tag que vous recherchez via /.

Une vue plus compacte ( --pretty=oneline) plus toutes les têtes ( -a) pourrait également aider:

git log -a --pretty=oneline --graph |git name-rev --stdin --tags |less

Semble un peu terrifiant, mais pourrait également être aliasé ~/.gitconfigsi nécessaire.

~/.gitconfig

[alias]
ls-tags = !git log -a --pretty=oneline --graph |git name-rev --stdin --tags |less

4

Réponse courte post-Git-2

Je sais que cette question est posée depuis un bon moment. Et la réponse de CB Bailey est 100% correcte:git show-ref --tags --abbrev

J'aime mieux celui-ci car il utilise git tag:

git tag --list --format '%(refname:short) %(objectname:short)'

Facile. Court.

PS alias comme git taglistavec cette commande:

git config --global alias.taglist "tag --list --format '%(refname:short) %(objectname:short)'"

3

À partir de la liste de diffusion git , voici le moyen d'obtenir la liste des hachages de validation pour les balises avec déréférencement automatique pour les balises annotées:

git for-each-ref --format='%(if)%(*objectname)%(then)%(*objectname)%(else)%(objectname)%(end) %(refname)' refs/tags

2

Cela ne montre pas les noms de fichiers, mais au moins vous avez une idée du référentiel.

cat .git/refs/tags/*

Chaque fichier de ce répertoire contient un SHA de validation pointant vers une validation.


Cela n'a pas fonctionné car, je pense, j'ai retiré les balises de la télécommande. .git/packed-refsa fonctionné cependant.
Igor Zevaka

2

J'aimerais aussi savoir la bonne façon , mais vous pouvez toujours jeter un coup d'œil sur:

$ cat .git/packed-refs 

ou:

$ cat .git/refs/tags/*

C'est vrai, donc le comportement des emballages-refs et des refs / tags est quelque peu différent, pack-refs est un fichier texte contenant des balises et des SHA, tandis que refs / tags / est un répertoire avec des fichiers texte nommés d'après une balise contenant le SHA. En fait, je pense que la bonne façon de procéder est avec git rev-list.
Igor Zevaka

2

Cela vous donnera le hachage SHA1 actuel

Hachage de validation abrégé

git show <tag> --format="%h" --> 42e646e

Valider le hachage

git show <tag> --format="%H" --> 42e646ea3483e156c58cf68925545fffaf4fb280

1
ne semble pas fonctionner dans la version que j'ai, mais git log <tag> -n 1 --pretty=%Hfonctionne
Andy

2

Si vous souhaitez voir les détails de la balise SOMETAG (tagger, date, etc.), le hachage du commit vers lequel il pointe et un peu d'informations sur le commit mais sans le diff complet, essayez

git show --name-status SOMETAG

Exemple de sortie:

tag SOMETAG
Tagger: ....
Date:   Thu Jan 26 17:40:53 2017 +0100

 .... tag message .......

commit 9f00ce27c924c7e972e96be7392918b826a3fad9
Author: .............
Date:   Thu Jan 26 17:38:35 2017 +0100

 .... commit message .......

..... list of changed files with their change-status (like git log --name-status) .....

0

J'ai donc une charge de dossiers de versions, où ces dossiers peuvent être extraits de l'un des quelques référentiels différents, et peuvent être des branches dev, qa ou master ou peuvent être des versions de production, extraites d'une balise et la balise peut être annoté ou non. J'ai un script qui examinera le dossier cible et obtiendra une réponse sous la forme -. Le problème est que différentes versions de git renvoient un statut différent 'pour une extraction de balise.

J'ai donc trouvé git show-ref --tagstravaillé initialement, à l'exception des balises annotées. Cependant, l'ajout de -d a ajouté une entrée distincte à la liste des balises, une pour la balise, l'autre pour l'annotation (la validation d'annotation a été identifiée comme ^ {} que j'ai supprimée avec sed).

C'est donc le cœur de mon script, pour tous ceux qui le souhaitent: -

REPO=`git --git-dir=${TARGET} remote show origin -n | \
         grep "Fetch URL:" | \
         sed -E "s/^.*\/(.*)$/\1/" | \
         sed "s/.git$//"`

TAG=`git --git-dir=${TARGET} show-ref -d --tags | \
         grep \`git --git-dir=${TARGET} show --quiet --format=format:%H HEAD\` | \
         cut -d\  -f2 | \
         cut -d/ -f3 | \
         sed "s/\^{}$//"`

if [ "${TAG}" == "" ] ; then 
  BRANCH=`git --git-dir=${TARGET} show-ref --heads | \
         grep \`git --git-dir=${TARGET} show --quiet --format=format:%H HEAD\` | \
         cut -d\  -f2 | \
         cut -d/ -f3`
  TAG=${BRANCH}
fi

0

Peut utiliser ci-dessous, il donnera le hachage de validation
git show -s --format=%H <tag>^{commit}

Si un hachage de validation abrégé est requis, git show -s --format=%h <tag>^{commit}

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.