Pourquoi devrais-je me soucier des balises légères ou annotées?


346

L'année dernière, je suis passé de Subversion à Git en tant que VCS et j'essaie toujours de saisir les points les plus fins de "Git-think".

Celui qui me dérange ces derniers temps est "léger" vs tags annotés vs signés. Il semble assez universellement admis que les balises annotées sont supérieures aux balises légères pour toutes les utilisations réelles, mais les explications que j'ai trouvées pour lesquelles c'est le cas semblent toujours se résumer à "parce que les meilleures pratiques" ou "parce qu'elles sont différentes" . Malheureusement, ce sont des arguments très insatisfaisants sans savoir pourquoi ce sont les meilleures pratiques ou comment ces différences sont pertinentes pour mon utilisation de Git.

Lorsque je suis passé à Git pour la première fois, les étiquettes légères semblaient être la meilleure chose depuis le pain en tranches; Je pourrais juste pointer du doigt sur un commit et dire "c'était 1.0". J'ai du mal à comprendre comment un tag pourrait avoir besoin d'être plus que cela, mais je ne peux certainement pas croire que les experts Git du monde préfèrent arbitrairement les tags annotés! Alors, quel est le brouhaha?

(Points bonus: pourquoi aurais-je besoin de signer une étiquette?)

ÉDITER

J'ai été convaincu avec succès que les balises annotées sont une bonne chose - savoir qui a marqué et quand est important! À titre de suivi, des conseils sur les bonnes annotations de balises? Les deux git tag -am "tagging 1.0" 1.0et essayer de résumer le journal de validation depuis la balise précédente ont l'impression de perdre des stratégies.


Avez-vous trouvé une bonne réponse pour votre suivi? Quelque chose comme? git log --pretty=oneline master..HEAD | git tag -a -F - $BRANCH.$BUILD_NUMBER
dalore

Résumer le journal de validation depuis la balise précédente me semble être une excellente stratégie pour les messages de balise.
rooby

FYI (1.) Pour lister les balises LIGHTWEIGHT par date, allez ici . (2.) Pour lister les balises ANNOTÉES par date, allez ici .
Trevor Boyd Smith

Réponses:


272

Le gros plus d'une balise annotée est que vous savez qui l'a créée. Tout comme avec les commits, il est parfois agréable de savoir qui l'a fait. Si vous êtes développeur et que vous voyez que la v1.7.4 a été balisée (déclarée prête) et que vous n'êtes pas sûr, à qui parlez-vous? La personne dont le nom est dans la balise annotée! (Si vous vivez dans un monde méfiant, cela empêche également les gens de s'en tirer avec des choses qu'ils ne devraient pas étiqueter.) Si vous êtes un consommateur, ce nom est un sceau d'autorité: c'est Junio ​​Hamano disant que cette version de git est par les présentes libéré.

Les autres métadonnées peuvent également être utiles - il est parfois agréable de savoir quand cette version a été publiée, pas seulement lorsque la validation finale a été effectuée. Et parfois, le message peut même être utile. Peut-être que cela aide à expliquer le but de cette balise particulière. Peut-être que la balise d'un candidat à la version contient un peu d'une liste d'état / de tâches.

Signer des balises est à peu près comme signer autre chose - cela fournit un niveau de sécurité supplémentaire pour le paranoïaque. La plupart d'entre nous ne vont jamais l'utiliser, mais si vous voulez vraiment tout vérifier avant de mettre ce logiciel sur votre ordinateur, vous le voudrez peut-être.

Éditer:

Quant à ce qu'il faut écrire dans une annotation de balise, vous avez raison - il n'y a pas toujours beaucoup d'utilité à dire. Pour une balise de numéro de version, il est implicitement entendu qu'elle marque cette version, et si vous êtes satisfait de vos journaux de modifications ailleurs, il n'est pas nécessaire d'en mettre une ici. Dans ce cas, c'est vraiment le tagueur et la date qui sont les plus importants. La seule autre chose à laquelle je peux penser est une sorte de tampon d'approbation d'une suite de tests. Jetez un œil aux tags de git.git: ils disent tous quelque chose comme "Git 1.7.3 rc1"; tout ce qui nous intéresse vraiment, c'est le nom de Junio ​​Hamano sur eux.

Cependant, pour les balises moins clairement nommées, le message pourrait devenir beaucoup plus important. Je pourrais envisager d'étiqueter une version spécifique pour un utilisateur / client unique, un jalon important non lié à la version ou (comme mentionné ci-dessus) une version candidate avec des informations supplémentaires. Le message est alors beaucoup plus utile.


4
juste pour comparer avec SVN, puisque l'OP provient de ce système: les métadonnées de balise annotées sont équivalentes au changement SVN réel qui fait la branche de balise, qui dans SVN a son propre auteur et message. Et, potentiellement, des restrictions distinctes sur qui peut créer une balise, distinctes de qui peut enregistrer des modifications - une distinction qui n'est pas pertinente si vous utilisez simplement le système pour vos propres trucs.
araqnid

10
Ah-ha! Il semble que ma compréhension ici ait été entravée par le fait que tous mes projets Git jusqu'à présent ont été en solo. Je n'ai jamais eu besoin de savoir qui blâmer pour quelque chose (c'est toujours moi!), Donc je n'avais pas remarqué que les balises légères ne suivaient pas le tagueur.
Ben Blank

5
git help logrésume maintenant cela comme suit: "Les balises annotées sont destinées à être publiées tandis que les balises légères sont destinées aux étiquettes d'objets privés ou temporaires."
Jon Gjengset

1
@javabrett Bien que ce soit une bonne partie de la réponse à "quelles sont les différences entre les balises annotées et légères", la question ici était précisément pourquoi les gens veulent stocker des informations supplémentaires et donc utiliser des balises annotées. (Et je ne pense pas que je pourrais sérieusement dire que "cela crée un blob" est un inconvénient - vous faites ce que vous devez faire pour stocker les informations que vous souhaitez stocker, et si ce sont des informations importantes, cela nécessitera un blob. )
Cascabel

1
@Chris oui, comme le dit la réponse: "Le gros plus d'un tag annoté est que vous savez qui l'a créé." Vous pouvez toujours essayer les choses par vous-même pour découvrir:git tag -a -m 'my message' my-tag; git show my-tag
Cascabel

64

Mon point de vue personnel, légèrement différent sur ce sujet:

  • Les balises annotées sont les balises destinées à être publiées pour d'autres développeurs, très probablement de nouvelles versions (qui devraient également être signées). Non seulement pour voir qui a été tagué et quand il a été tagué, mais aussi pourquoi (généralement un journal des modifications).
  • Les poids légers sont plus appropriés pour un usage privé, ce qui signifie que le marquage des validations spéciales permet de les retrouver. Que ce soit pour les revoir, les vérifier pour tester quelque chose ou autre.

4
Ceci est également mentionné sur man git-tag: "Les balises annotées sont destinées à être libérées tandis que les balises légères sont destinées aux étiquettes d'objets privés ou temporaires.": Stackoverflow.com/a/35059291/895245
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功

28

Par défaut, Git ne regarde que les balises annotées comme ligne de base pour des commandes comme git describe. Considérez les balises annotées comme des panneaux de signalisation qui ont une signification durable pour vous-même et pour les autres, tandis que les balises légères sont plus comme des signets que vous pourrez retrouver plus tard. Par conséquent, les balises annotées valent la peine d'être utilisées comme référence, tandis que les balises légères ne devraient pas l'être.

La signature d'une étiquette est une garantie de l'identité du signataire. Il permet aux utilisateurs de vérifier, par exemple, que le code du noyau Linux qu'ils ont récupéré est le même que celui que Linus Torvalds a réellement publié. La signature peut également être une affirmation que le signataire se porte garant de la qualité et de l'intégrité du logiciel lors de cette validation.


1
git push --follow-tagsest une autre commande qui traite les deux différemment: stackoverflow.com/a/26438076/895245
Ciro Santilli 法轮功 冠状 病 六四 事件 法轮功

1
Merci pour l'astuce git describe. Je l'utilise dans le système d'intégration continue et quelques fois la chaîne de version n'était pas ce à quoi je m'attendais.
jjmontes

9

La signature d'une balise est un moyen facile d'affirmer l'authenticité d'une version.

Ceci est particulièrement utile dans un DVCS car n'importe qui peut cloner le référentiel et modifier l'historique (par exemple via git-filter-branch). Si une balise est signée, la signature ne survivra pas à une opération git-filter-branch, donc si vous avez une politique selon laquelle chaque version est balisée et signée par un committer, il est possible de détecter une fausse étiquette de version dans le référentiel.

Si ce n'était pas pour la signature, je ne verrais pas grand-chose non plus dans les balises annotées.


1
En fait, pour cela, il pourrait être utile d'avoir une signature qui ne signe que l'arbre engagé, pas toute son histoire (peu importe si quelqu'un a falsifié l'histoire, je veux seulement être sûr d'avoir le bon code).
Paŭlo Ebermann

9

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

Certains comportements Git les différencient de manière 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 pour développer.

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

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ées ou temporaires.

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


6

J'ai trouvé le bon usage pour les balises légères - créer une version sur GitHub en rétrospective.

Nous avons publié notre logiciel et nous avons eu les commits nécessaires, nous n'avons tout simplement pas pris la peine de maintenir la section «Release» sur le GitHub. Et lorsque nous y avons prêté un peu d'attention, nous avons réalisé que nous voudrions également ajouter des versions précédentes, avec les anciennes dates de sortie correctes pour elles.

Si nous voulions simplement créer une balise annotée sur un ancien commit, GitHub prendrait la date de sortie de l'objet balise. En revanche, lorsque nous avons créé une balise légère pour cet ancien commit, la version a commencé à afficher la bonne (ancienne) date. Aide de Source @ GitHub, «À propos des versions»

Il semble qu'il soit également possible de spécifier la date souhaitée pour un commit annoté, mais cela ne me semble pas aussi simple: https://www.kernel.org/pub/software/scm/git/docs/git-tag. html # _on_backdating_tags


Bien qu'aujourd'hui, j'ai découvert que GitHub a cessé d'honorer les dates des balises pour moi (pour les balises légères et annotées). Il ignore simplement la date de publication de la version et se souvient de la date et de l'heure à laquelle j'ai appuyé sur le bouton "Publier" de la version.
evilkos

Oui, je suis également tombé sur ce gâchis concernant GitHub et les balises annotées. Je n'ai pas compris pourquoi ils l'ont implémenté de cette façon ..
YakovL

1

Dans mon bureau, nous mettrons l'adresse de la page Web de publication dans le corps de la balise. La page Web de la version détaille toutes les nouvelles fonctionnalités et correctifs depuis la dernière version. La direction ne cherchera pas dans le dépôt git pour savoir quels changements se sont produits, et c'est bien d'avoir une liste concise de ce qui est dans cette version.


0

Les balises annotées stockent des métadonnées supplémentaires telles que le nom de l'auteur, les notes de publication, le message de balise et la date en tant qu'objets complets dans la base de données Git. Toutes ces données sont importantes pour une diffusion publique de votre projet.

git tag -a v1.0.0

Les balises légères sont le moyen le plus simple d'ajouter une balise à votre référentiel git car elles ne stockent que le hachage du commit auquel elles se réfèrent. Ils peuvent agir comme des «signets» pour un commit, en tant que tels, ils sont parfaits pour un usage privé.

git tag v1.0.0

Vous pouvez trier, répertorier, supprimer, afficher et modifier les anciennes balises. Toutes ces fonctions vous aideront à identifier des versions spécifiques de votre code. J'ai trouvé cet article qui pourrait vous aider à avoir une meilleure idée de ce que les balises peuvent faire.


0

Pour moi, la différence importante est que la balise légère n'a pas d'horodatage. Supposons que vous ayez ajouté plusieurs balises légères:

git tag v1
git tag v2
git tag v3

puis, peut-être plus tard, vous souhaitez obtenir la dernière balise légère ajoutée. Il n'y a aucun moyen de le faire. Ni "git describe" ni "git tag" ne vous donneront chronologiquement la dernière balise légère. "git tag -l" peut les renvoyer tous ou les trier par ordre lex, mais pas par date / heure. "git describe --tags" renverra "v1" qui n'est certainement pas la dernière balise ajoutée.

D'un autre côté, si vous ajoutez des balises annotées:

git tag v1 -m v1
git tag v2 -m v1
git tag v3 -m v1

vous pouvez toujours obtenir l'horodatage de chaque balise et "git describe" renverra certainement "v3" qui est vraiment la dernière balise ajoutée.


Vous devez utiliser -a pour qu'il soit annoté.
Alex
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.