web-dev-qa-db-fra.com

Pourquoi devrais-je me préoccuper des tags légers par rapport aux tags annotés?

Je suis passé de Subversion à Git en tant que VCS au jour le jour l'année dernière et j'essaie toujours de saisir les subtilités de "Git-think".

Celui qui me dérange depuis quelque temps est "léger" par rapport aux balises annotées et signées. Il semble assez universellement admis que les balises annotées sont supérieures aux balises légères pour tous les usages réels, mais les explications que j'ai trouvées sur ce point semblent toujours résumer comme suit: "car meilleures pratiques" ou " parce qu'ils sont différents " . Malheureusement, ce sont des arguments très peu satisfaisants sans savoir pourquoi ce sont les meilleures pratiques ou comment ces différences sont pertinentes à mon utilisation de Git.

Lorsque je suis passé chez Git, les étiquettes légères semblaient être la meilleure chose depuis le pain en tranches; Je pourrais juste indiquer un commit et dire "c'était 1.0". Je n'arrive pas à comprendre comment un tag devrait être plus que cela, mais je ne peux certainement pas croire que les experts Git du monde préfèrent les tags annotés de manière arbitraire! Alors, qu'est-ce que tout ce brouhaha?

(Points bonus: Pourquoi aurais-je besoin de signer un tag?)}

MODIFIER

J'ai été convaincu avec succès que les tags annotés sont une bonne chose - savoir qui a tagué et quand est important! En guise de suivi, des conseils sur les bonnes annotations de balises? git tag -am "tagging 1.0" 1.0 et l’essai de synthèse du journal de validation depuis la balise précédente donnent l’impression de perdre des stratégies.

gitgit-tag
309
Ben Blank

Le gros avantage d'une balise annotée est que vous savez qui l'a créée. Comme avec les commits, il est parfois agréable de savoir qui l’a fait. Si vous êtes un développeur et que vous voyez que la v1.7.4 a été étiquetée (déclarée prête) et que vous n’êtes pas si sûre de qui, vous parlez à qui? 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 marquer des choses qu'ils ne devraient pas.) Si vous êtes un consommateur, ce nom est une empreinte d'autorité: c'est Junio ​​Hamano qui dit que cette version de git est par la présente. 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, et pas seulement quand le commit final a été effectué. Et parfois, le message peut même être utile. Peut-être que cela peut aider à expliquer le but de cette balise particulière. Peut-être que la balise pour une version candidate contient un peu de liste de statut/tâches à faire.

Signer des tags ressemble à quoi que ce soit d'autre. Cela fournit un niveau de sécurité supplémentaire pour les paranoïaques. La plupart d'entre nous ne l'utiliseront jamais, mais si vous voulez vraiment tout vérifier avant d'installer ce logiciel sur votre ordinateur, vous le voudrez peut-être.

Modifier:

Vous avez raison de savoir ce qu'il faut écrire dans une annotation de balise. Il n'y a pas toujours beaucoup d'utile à dire. Pour une balise de numéro de version, il est implicitement compris qu'elle marque cette version et si vous êtes satisfait de vos fichiers de modifications ailleurs, vous n'avez pas besoin de les ajouter. Dans ce cas, c’est le tagger et la date qui importent le plus. La seule autre chose à laquelle je peux penser est une sorte de tampon d'approbation d'une suite de tests. Regardez les tags de git.git: ils disent tous quelque chose comme "Git 1.7.3 rc1"; tout ce qui nous intéresse, c'est le nom de Junio ​​Hamano.

Cependant, pour les tags moins clairement nommés, le message pourrait devenir beaucoup plus important. Je pourrais envisager de marquer une version spéciale à usage spécifique pour un utilisateur/client unique, une étape importante autre que la version ou (comme mentionné ci-dessus) une version candidate avec des informations supplémentaires. Le message est alors beaucoup plus utile.

244
Cascabel

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 par d'autres développeurs, très probablement de nouvelles versions (qui doivent également être signées). Non seulement pour voir qui a tagué et quand il a été tagué, mais aussi pourquoi (généralement un changelog).
  • Lightweight sont plus appropriés pour un usage privé, cela signifie que les balises spéciales doivent être marquées pour pouvoir les retrouver. Que ce soit pour les examiner, les vérifier pour tester quelque chose ou autre.
59
Koraktor

Par défaut, Git considère uniquement les balises annotées comme une référence pour des commandes telles que git describe. Pensez aux étiquettes annotées en tant que panneaux indicateurs ayant une signification durable pour vous-même et les autres, tandis que les étiquettes légères ressemblent davantage à des signets que vous pourrez retrouver plus tard. Par conséquent, les balises annotées peuvent être utilisées comme référence, alors que les balises légères ne devraient pas l'être.

Signer une étiquette est une assurance de l'identité du signataire. Cela permet aux utilisateurs de vérifier, par exemple, que le code du noyau Linux qu'ils ont récupéré est identique à celui que Linus Torvalds a réellement publié. La signature peut également être une affirmation que le signataire atteste de la qualité et de l'intégrité du logiciel lors de la validation.

25
Phil Miller

La signature d'un tag est un moyen simple d'affirmer l'authenticité d'une version.

Ceci est particulièrement utile dans un DVCS car tout le monde 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 de branche git-filter-branch. Par conséquent, si vous avez pour règle que chaque version est étiquetée et signée par un responsable, il est possible de détecter une balise de publication fictive dans le référentiel.

Sans la signature, je ne verrais pas beaucoup l'intérêt des balises annotées.

9
cwilper

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

Certains comportements Git les différencient de telle manière que cette recommandation soit utile, par exemple:

  • les balises annotées peuvent contenir un message, un créateur et une date différente de celle du commit sur lequel elles pointent. Vous pouvez donc les utiliser pour décrire une version sans effectuer de validation.

    Les balises légères n'ont pas cette information supplémentaire, et n'en ont pas besoin, puisque vous ne l'utiliserez que pour vous développer.

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

man git-tag dit:

Les étiquettes annotées sont destinées à être publiées, tandis que les étiquettes légères sont destinées aux étiquettes d'objets privés ou temporaires.

Différences internes

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

  • pour les tags légers, le SHA-1 pointe directement sur un commit:

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

    imprime le même que le SHA-1 de HEAD.

    Il n’est donc pas étonnant qu’ils ne puissent contenir aucune autre métadonnée.

  • les étiquettes annotées pointent sur un objet étiquette 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 tag annoté:

    c1d7720e99f9dd1d1c8aee625fd6ce09b3a81fef

    et alors 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 voici comment il contient des métadonnées supplémentaires. Comme nous pouvons le voir à la sortie, les champs de métadonnées sont:

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

Bonus

6
Ciro Santilli 新疆改造中心 六四事件 法轮功

J'ai trouvé le bon usage des balises légères: créer une version rétrospective de GitHub.

Nous avons publié notre logiciel et nous avions les commits nécessaires. Nous n'avons simplement pas pris la peine de maintenir la section «Publication» sur le GitHub. Et lorsque nous avons accordé un peu d'attention à cela, nous avons réalisé que nous souhaitions également ajouter des versions précédentes, avec les anciennes dates de version correctes. 

Si nous voulions simplement créer une balise annotée sur un ancien commit, GitHub prendrait la date de publication 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 date correcte (ancienne) Aide 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

6
evilkos

Dans mon bureau, nous mettrons l'adresse de la page Web de la version dans le corps de la balise. La page Web de la version détaille toutes les nouvelles fonctionnalités et corrections depuis la dernière version. La direction ne cherchera pas dans le dépôt git pour savoir quels changements ont eu lieu, et il est agréable d'avoir une liste concise des éléments de cette version. 

1
David

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 sous forme d'objets complets dans la base de données Git. Toutes ces données sont importantes pour la publication de votre projet.

balise git -a v1.0.0

Les balises légères constituent 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 font référence. Ils peuvent agir comme des "signets" pour un commit, ils sont donc 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
Nesha Zoric

Pour moi, une différence importante est que les balises légères n'ont pas d'horodatage. Disons que vous avez ajouté plusieurs balises légères:

git tag v1
git tag v2
git tag v3

et puis, peut-être plus tard, vous voulez obtenir la dernière balise légère ajoutée. Il n'y a pas moyen de le faire. Ni "git decrire" ni "git tag" ne vous donneront pas chronologiquement le dernier tag léger. "git tag -l" peut tous les retourner ou les trier dans l'ordre de Lex, mais pas par date/heure. "git describe --tags" retournera "v1" qui n'est certainement pas la dernière balise ajoutée.

D'autre part, 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 decrire" retournera "v3" qui est vraiment la dernière balise ajoutée.

0
Ezh