git tag
Dans ce document, nous verrons le concept de tags Git et la commande git tag. Les tags sont des réfs qui pointent vers des points spécifiques de l'historique Git. Les tags sont généralement utilisés pour capturer un point de l'historique utilisé pour une version marquée (c.-à-d., v1.0.1). Un tag est similaire à une branche qui ne change pas. Contrairement aux branches, après leur création, les tags ne possèdent plus d'historique des commits. Pour en savoir plus sur les branches, consultez la page git branch. Ce document aborde les différents types de tags, comment en créer, les répertorier, les supprimer, les partager, et bien plus.
Créer un tag
Pour créer un tag, exécutez la commande suivante :
git tag <tagname>Remplacez < tagname > par un identifiant sémantique à l'état du dépôt au moment de la création du tag. Un schéma courant consiste à utiliser des numéros de version, comme git tag v1.4. Git prend en charge deux types de tags différents : annotés et légers. Dans l'exemple précédent, nous avons créé un tag léger. Les tags légers et les tags annotés diffèrent dans la quantité de métadonnées associées qui sont stockées. Une bonne pratique consiste à considérer les tags annotés comme publics et les tags légers, comme privés. Les tags annotés stockent des métadonnées supplémentaires, comme : le nom du créateur du tag, son e-mail et la date. Ces données sont importantes pour une version publique. Les tags légers sont des « signets » associés à un commit. Ce ne sont rien de plus qu'un nom et un pointeur vers un commit. Ils sont utiles pour créer des liens rapides vers des commits pertinents.
Annotated tags
Les tags annotés sont stockés comme des objets complets dans la base de données Git. Pour rappel, ils stockent des métadonnées supplémentaires, comme : le nom du créateur du tag, son e-mail et la date. À l'instar des commits et des messages de commit, les tags annotés possèdent un message de tag. En outre, pour des raisons de sécurité, les tags annotés peuvent être signés et vérifiés grâce à GNU Privacy Guard (GPG). Bonne pratique recommandée : pour Git, préférez les tags annotés aux tags légers pour bénéficier de toutes les métadonnées associées.
git tag -a v1.4Lorsque vous exécutez cette commande, vous créez un tag annoté identifié par v1.4. La commande ouvre ensuite l'éditeur de texte par défaut configuré et invite à saisir des métadonnées supplémentaires.
git tag -a v1.4 -m "my version 1.4"Cette commande est similaire à l'appel précédent. Cependant, cette version est transmise avec l'option -m et un message. Cette méthode pratique rappelle git commit -m. Elle crée immédiatement un tag et annule l'ouverture de l'éditeur de texte local. À la place, elle enregistre le message transmis grâce à l'option -m.
Ressource connexe
Fiche de révision sur Git
DÉCOUVRIR LA SOLUTION
Découvrir Git avec Bitbucket Cloud
Lightweight tags
git tag v1.4-lwCette commande crée un tag léger identifié par v1.4-lw.. Les tags légers sont créés sans l'option -a, -s ou -m. Ils créent une somme de contrôle de tag et la stockent dans le répertoire .git/ du dépôt de projet.
Listing tags
Pour répertorier les tags stockés dans un dépôt, exécutez la commande suivante :
git tagUne liste des tags sera alors générée :
v0.10.0
v0.10.0-rc1
v0.11.0
v0.11.0-rc1
v0.11.1
v0.11.2
v0.12.0
v0.12.0-rc1
v0.12.1
v0.12.2
v0.13.0
v0.13.0-rc1
v0.13.0-rc2Pour affiner la liste des tags, vous pouvez transmettre l'option -l avec une expression générique :
$ git tag -l *-rc*
v0.10.0-rc1
v0.11.0-rc1
v0.12.0-rc1
v0.13.0-rc1
v0.13.0-rc2
v0.14.0-rc1
v0.9.0-rc1
v15.0.0-rc.1
v15.0.0-rc.2
v15.4.0-rc.3L'exemple précédent utilise l'option -l et une expression générique de -rc qui renvoie une liste de tous les tags marqués par le préfixe -rc, traditionnellement utilisé pour identifier les candidats à la livraison.
Tagging old commits
Les exemples de tag précédents montrent des opérations sur des commits implicites. Par défaut, git tag crée un tag sur le commit référencé par HEAD. Sinon, git tag peut être transmise en tant que réf à un commit spécifique. Le commit transmis est alors tagué, et non défini par défaut sur HEAD. Pour collecter une liste d'anciens commits, exécutez la commande git log.
$ git log --pretty=oneline
15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'feature'
a6b4c97498bd301d84096da251c98a07c7723e65 add update method for thing
0d52aaab4479697da7686c15f77a3d64d9165190 one more thing
6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment'Lorsque vous exécutez git log, vous générez une liste de commits. Dans cet exemple, nous sélectionnons le commit le plus élevé, Merge branch 'feature' pour le nouveau tag. Nous devons faire une référence à l'empreinte SHA du commit pour la transmettre à Git :
git tag -a v1.2 15027957951b64cf874c3557a0f3547bd83b3ff6
Lorsque vous appelez git tag comme indiqué ci-dessus, vous créez un commit annoté identifié par v1.2 pour le commit sélectionné dans l'exemple git log précédent.
ReTagging/Replacing old tags
Si vous essayez de créer un tag portant le même identifiant qu'un tag existant, Git renvoie une erreur comme celle-ci :
fatal: tag 'v0.4' already existsEn outre, si vous essayez de taguer un ancien commit avec un identifiant de tag existant, Git renvoie la même erreur.
Si vous devez mettre à jour un tag existant, vous devez utiliser l'option -f (FORCER).
git tag -a -f v1.4 15027957951b64cf874c3557a0f3547bd83b3ff6
Lorsque vous exécutez la commande ci-dessus, vous mappez le commit 15027957951b64cf874c3557a0f3547bd83b3ff6 à l'identifiant de tag v1.4. Tout contenu existant pour le tag v1.4 est écrasé.
Sharing: Pushing tags to remote
Le partage de tags est similaire au push de branches. Par défaut, git push ne fait pas de push de tags. Les tags doivent être explicitement transmis à git push.
$ git push origin v1.4
Counting objects: 14, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (12/12), done.
Writing objects: 100% (14/14), 2.05 KiB | 0 bytes/s, done.
Total 14 (delta 3), reused 0 (delta 0)
To git@bitbucket.com:atlasbro/gittagdocs.git
* [new tag] v1.4 -> v1.4Pour faire un push de plusieurs tags simultanément, transmettez l'option --tags à la commande git push. Lorsqu'un autre utilisateur clone un dépôt ou en fait un pull, il reçoit les nouveaux tags.
Checking out tags
You can view the state of a repo at a tag by using the git checkout command.
git checkout v1.4La commande ci-dessus fait un check-out du tag v1.4. Le dépôt se retrouve alors à l'état HEAD détaché. Cela signifie que tout changement apporté ne mettra pas à jour le tag. Il créera un commit détaché. Ce nouveau commit détaché ne fera pas partie d'une branche et sera seulement joignable en utilisant l'empreinte SHA du commit. Par conséquent, il est recommandé de créer une branche dès que vous apportez des changements à un état HEAD détaché.
Deleting tags
La suppression de tags est une opération simple. Transmettez l'option -d et un identifiant de tag à git tag pour supprimer le tag identifié.
$ git tag
v1
v2
v3
$ git tag -d v1
$ git tag
v2
v3Dans cet exemple git tag est exécutée pour afficher une liste de tags montrant v1, v2 et v3. Ensuite, git tag -d v1 est exécutée pour supprimer le tag v1.
Résumé
To recap, Tagging is an additional mechanism used to create a snap shot of a Git repo. Tagging is traditionally used to create semantic version number identifier tags that correspond to software release cycles. The git tag command is the primary driver of tag: creation, modification and deletion. There are two types of tags; annotated and lightweight. Annotated tags are generally the better practices as they store additional valuable meta data about the tag. Additional Git commands covered in this document were git push, and git checkout. Visit their corresponding pages for discussion on their extended use.
Partager cet article
Thème suivant
Lectures recommandées
Ajoutez ces ressources à vos favoris pour en savoir plus sur les types d'équipes DevOps, ou pour les mises à jour continues de DevOps chez Atlassian.
Le blog Bitbucket
Parcours de formation DevOps
