Quelle est la différence entre une balise annotée et non annotée?


333

Si je veux marquer le commit actuel. Je sais que les deux lignes de commande suivantes fonctionnent:

git tag <tagname>

et

git tag -a <tagname> -m '<message>'

Quelle est la différence entre ces commandes?



1
@Thilo Ce n'est pas un doublon exact. La question référencée concerne le moment d'annoter, pas les indicateurs associés.
Todd A. Jacobs,

1
Ceci est très bien expliqué dans la documentation de Git: git-scm.com/book/en/Git-Basics-Tagging
Samy Dindane

TLDR non annoté: commit; annoté: commit, auteur, date, (facultatif) commentaire
Antony Hatchkins

Réponses:


255

TL; DR

La différence entre les commandes est que l'une vous fournit un message d'étiquette tandis que l'autre ne le fait pas. Une balise annotée a un message qui peut être affiché avec git-show (1), tandis qu'une balise sans annotations n'est qu'un pointeur nommé vers une validation.

En savoir plus sur les balises légères

Selon la documentation : "Pour créer une balise légère, ne fournissez aucune des options -a, -s ou -m, indiquez simplement un nom de balise". Il existe également différentes options pour écrire un message sur des balises annotées:

  • Lorsque vous utilisez git tag <tagname>, Git créera une balise à la révision actuelle mais ne vous demandera pas d'annotation. Il sera marqué sans message (il s'agit d'une balise légère).
  • Lorsque vous utilisez git tag -a <tagname>, Git vous demandera une annotation sauf si vous avez également utilisé l'indicateur -m pour fournir un message.
  • Lorsque vous utilisez git tag -a -m <msg> <tagname>, Git marquera le commit et l'annotera avec le message fourni.
  • Lorsque vous utilisez git tag -m <msg> <tagname>, Git se comportera comme si vous aviez passé l'indicateur -a pour l'annotation et utiliser le message fourni.

Fondamentalement, cela revient à savoir si vous souhaitez que la balise ait une annotation et d'autres informations associées ou non.


4
Existe-t-il une différence entre une balise "annotation" et un message de validation?
Steve Bennett

3
@SteveBennett Oui. Une annotation de balise n'est pas un message de validation. Vous ne pouvez pas le voir avec git-log (1); vous devez utiliser git-show (1).
Todd A. Jacobs

115
La différence entre les balises "annotées" et "légères" va au-delà du message. Vous pouvez avoir une balise annotée sans message ( git tag -a <tag> -m ''), mais une balise annotée a toujours un tagueur (auteur) et une date .
Piotr Findeisen

1
Pareil pour moi. Les balises de version ont généralement des messages assez inutiles (peut-il en dire plus que le nom? Pourquoi?). Malheureusement, cette réponse la plus votée ne mentionne pas cette différence.
Piotr Findeisen

44
Une autre chose importante à noter est que lorsque vous poussez vos balises vers un référentiel distant en utilisant git push --follow-tags, seules les balises annotées seront poussées.
Xatoo

209

Poussez les balises annotées, gardez la légèreté locale

man git-tag dit:

Les balises annotées sont destinées à la publication tandis que les balises légères sont destinées aux étiquettes d'objets privés ou temporaires.

Et certains comportements les différencient de manière à ce que cette recommandation soit utile, par exemple:

  • Les balises annotées peuvent contenir un message, un créateur et une date différents de la validation vers laquelle ils pointent. Vous pouvez donc les utiliser pour décrire une version sans effectuer de validation de version.

    Les balises légères n'ont pas ces informations supplémentaires et n'en ont pas besoin, car vous ne les utiliserez que vous-même pour développer.

  • git push --follow-tags ne poussera que les balises annotées
  • git describe sans options de ligne de commande ne voit que les balises annotées

Différences internes

  • les balises légères et annotées sont un fichier sous .git/refs/tagsqui contient un SHA-1

  • pour les balises légères, le SHA-1 pointe directement vers un commit:

    git tag light
    cat .git/refs/tags/light
    

    imprime la même chose que le SHA-1 de la TETE.

    Il n'est donc pas étonnant qu'ils ne puissent pas contenir d'autres métadonnées.

  • les balises annotées pointent vers un objet balise dans la base de données d'objets.

    git tag -as -m msg annot
    cat .git/refs/tags/annot
    

    contient le SHA de l'objet balise annoté:

    c1d7720e99f9dd1d1c8aee625fd6ce09b3a81fef
    

    puis nous pouvons obtenir son contenu avec:

    git cat-file -p c1d7720e99f9dd1d1c8aee625fd6ce09b3a81fef
    

    exemple de sortie:

    object 4284c41353e51a07e4ed4192ad2e9eaada9c059f
    type commit
    tag annot
    tagger Ciro Santilli <your@mail.com> 1411478848 +0200
    
    msg
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.11 (GNU/Linux)
    
    <YOUR PGP SIGNATURE>
    -----END PGP SIGNAT
    

    Et c'est ainsi qu'il contient des métadonnées supplémentaires. Comme nous pouvons le voir sur la sortie, les champs de métadonnées sont:

    Une analyse plus détaillée du format est présentée à: Quel est le format d'un objet tag git et comment calculer son SHA?

Bonus

  • Déterminez si une balise est annotée:

    git cat-file -t tag
    

    Les sorties

    • commit pour léger, puisqu'il n'y a pas d'objet tag, il pointe directement sur le commit
    • tag pour annoté, car il y a un objet tag dans ce cas
  • Afficher uniquement les balises légères: comment répertorier toutes les balises légères?


1
C'est beaucoup plus clair que la réponse actuellement acceptée. Merci.
Reece

43

La grande différence est parfaitement expliquée ici .

Fondamentalement, les balises légères ne sont que des pointeurs vers des validations spécifiques. Aucune autre information n'est enregistrée ; d'autre part, les balises annotées sont des objets normaux , qui ont un auteur et une date et peuvent être référencés car ils ont leur propre clé SHA.

Si savoir qui a marqué quoi et quand est pertinent pour vous, utilisez des balises annotées. Si vous souhaitez simplement marquer un point spécifique de votre développement , peu importe qui et quand l'a fait, les balises légères sont suffisantes.

Normalement, vous opterez pour des balises annotées, mais cela dépend vraiment du maître Git du projet.

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.