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

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.

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.

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.

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.

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.

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 <[email protected]> 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:

  • l'objet vers lequel il pointe
  • le type d'objet vers lequel il pointe. Oui, les objets tag peuvent pointer vers tout autre type d'objet comme les blobs, pas seulement les commits .
  • le nom du tag
  • identité et horodatage du tagueur
  • message. Notez comment la signature PGP vient d'être ajoutée au message

  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
  

  Sorties commitpour léger, tagpour annoté.

• Lister uniquement les balises légères: comment répertorier toutes les balises légères?

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

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.

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.

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.