Commençons par expliquer ce qu'est une balise dans git.

[!entrer la description de l'image ici][1]][1]

Un tag est utilisé pour étiqueter et marquer un commit spécifique dans l'historique.
Elle est généralement utilisée pour marquer les points de version (ex. v1.0, etc.).

Bien qu'une étiquette puisse sembler similaire à une branche, une étiquette, cependant, ne change pas.
Il pointe directement vers un commis spécifique dans l'historique.

[!entrer la description de l'image ici] [2]] [2]

Vous ne serez pas en mesure d'extraire les balises si elles ne sont pas localement dans votre dépôt, donc d'abord, vous devez " récupérer " les balises dans votre dépôt local.

D'abord, assurez-vous que la balise existe localement en faisant

# --all will fetch all the remotes.
# --tags will fetch all tags as well
git fetch --all --tags --prune

Puis vérifiez le tag en exécutant

git checkout tags/ -b 

Au lieu de origin, utilisez le préfixe tags/.

Dans cet exemple vous avez 2 tags version 1.0 &amp ; version 1.1 vous pouvez les extraire avec l'un des éléments suivants :

git checkout A  ...
git checkout version 1.0  ...
git checkout tags/version 1.0  ...

Toutes les balises ci-dessus feront la même chose puisque la balise n'est qu'un pointeur vers un commit donné.

[!entrer la description de l'image ici][3]][3] Origine : https://backlog.com/git-tutorial/img/post/stepup/capture_stepup4_1_1.png

Comment voir la liste de toutes les balises ?

# list all tags
git tag

# list all tags with given pattern ex: v-
git tag --list 'v-*'

Comment créer des balises ?

Il y a deux façons de créer une balise :

# lightweight tag 
git tag 

# annotated tag
git tag -a

La différence entre les deux est que lors de la création d'une balise annotée, vous pouvez ajouter des métadonnées comme vous le faites dans un commit git :
nom, e-mail, date, commentaire &amp ; signature

[!entrez la description de l'image ici][4]][4]

Comment supprimer les tags ?

# delete any given tag
git tag -d 

# Don't forget to remove the deleted tag form the server with push tags

Comment cloner un tag spécifique ?

Afin de récupérer le contenu d'un tag donné, vous pouvez utiliser la commande checkout.
Comme expliqué plus haut, les tags sont comme n'importe quel autre commit, nous pouvons donc utiliser checkout et au lieu d'utiliser le SHA-1, le remplacer simplement par tag_name.

Option 1:

# Update the local git repo with the latest tags from all remotes
git fetch --all

# checkout the specific tag
git checkout tags/ -b 

Option 2:

Utilisation de la commande clone

Puisque git supporte shallow clone en ajoutant le --branch à la commande clone, nous pouvons utiliser le nom du tag au lieu du nom de la branche. Git sait comment "traduire&quot ; le SHA-1 donné vers le commit correspondant.

# Clone a specific tag name using git clone 
 git clone  --branch=

git clone --branch=

-branch peut aussi prendre des tags et détache le HEAD à ce commit dans le dépôt résultant.

Comment pousser les balises ?

git push --tags

Pour pousser tous les tags :

git push --tags 

Pour pousser les balises annotées et les balises de la chaîne de l'historique actuel, utilisez : :

git push --follow-tags

Ce flag --follow-tags pousse à la fois les commits et seulement les tags qui sont les deux :

• Des balises annotées (pour que vous puissiez ignorer les balises locales/temporelles)
• Des tags atteignables (un ancêtre) de la branche courante (situés dans l'historique)

Depuis Git 2.4, vous pouvez le définir en utilisant la configuration

git config --global push.followTags true

[1] : https://i.stack.imgur.com/yRIIc.png [2] : https://i.stack.imgur.com/Xy20U.png [3] : https://i.stack.imgur.com/X4lvg.png [4] : https://i.stack.imgur.com/EwBtF.jpg

(Cette réponse m'a pris du temps à écrire, et la réponse de codeWizard's est correcte dans son but et son essence, mais pas entièrement complète, donc je la poste quand même).

Il n'existe pas de "balise Git distante". Il n'y a que des "tags". Je souligne tout cela non pas pour être pédant,1 mais parce qu'il y a beaucoup de confusion à ce sujet chez les utilisateurs occasionnels de Git, et la documentation de Git n'est pas très utile2 aux débutants. (Il n'est pas clair si la confusion vient d'une mauvaise documentation, ou si la mauvaise documentation vient du fait que c'est intrinsèquement un peu confus, ou quoi). Il existe des "branches distantes", plus correctement appelées "branches de suivi à distance", mais il convient de noter qu'il s'agit en fait d'entités locales. Il n'y a pas de balises distantes, cependant (sauf si vous les (ré)inventez). Il n'y a que des balises locales, donc vous devez obtenir la balise localement pour pouvoir l'utiliser. La forme générale des noms pour des commits spécifiques - que Git appelle references - est toute chaîne commençant par refs/. Une chaîne qui commence par refs/heads/ nomme une branche ; une chaîne qui commence par refs/remotes/ nomme une branche de suivi à distance ; et une chaîne qui commence par refs/tags/ nomme un tag. Le nom refs/stash est la référence de la cachette (telle qu'elle est utilisée par git stash ; notez l'absence de slash de fin). Il existe quelques noms inhabituels qui ne commencent pas par refs/ : HEAD, ORIG_HEAD, MERGE_HEAD, et CHERRY_PICK_HEAD en particulier sont tous des noms qui peuvent faire référence à des commits spécifiques (bien que HEAD contienne normalement le nom d'une branche, c'est-à-dire qu'il contient ref : refs/heads/branch). Mais en général, les références commencent par refs/. Une chose que Git fait pour rendre cela confus est qu'il vous permet d'omettre les refs/, et souvent le mot après refs/. Par exemple, vous pouvez omettre refs/heads/ ou refs/tags/ lorsque vous vous référez à une branche locale ou à un tag - et en fait vous doit omettre refs/heads/ lorsque vous extrayez une branche locale ! Vous pouvez le faire lorsque le résultat n'est pas ambigu ou, comme nous venons de le voir, lorsque vous devez le faire (pour git checkout branch). Il est vrai que les références existent non seulement dans votre propre dépôt, mais aussi dans des dépôts distants. Cependant, Git ne vous donne accès aux références d'un dépôt distant qu'à des moments très précis : à savoir, pendant les opérations fetch et push. Vous pouvez aussi utiliser git ls-remote ou git remote show pour les voir, mais fetch et push sont les points de contact les plus intéressants.

Refspecs

Pendant fetch et push, Git utilise des chaînes qu'il appelle refspecs pour transférer les références entre le dépôt local et le dépôt distant. C'est donc à ces moments, et via les refspecs, que deux dépôts Git peuvent se synchroniser l'un avec l'autre. Une fois que vos noms sont synchronisés, vous pouvez utiliser le même nom que celui que quelqu'un utilise dans le dépôt distant. Il y a cependant une magie spéciale sur fetch, et elle affecte à la fois les noms de branches et les noms de tags. Vous devriez penser que git fetch dirige votre Git pour appeler (ou peut-être envoyer un message texte) un autre Git - le "remote"- et avoir une conversation avec lui. Au début de cette conversation, le distant liste toutes ses références : tout ce qui est dans refs/heads/ et tout ce qui est dans refs/tags/, ainsi que toutes les autres références qu'il possède. Votre Git les parcourt et (en se basant sur la spécification habituelle de récupération des références) renomme leurs branches. Regardons la refspec normale pour le remote nommé origin :

$ git config --get-all remote.origin.fetch
+refs/heads/*:refs/remotes/origin/*
$ 

Cette refspec demande à votre Git de prendre chaque nom correspondant à refs/heads/* - c'est-à-dire chaque branche du distant - et de changer son nom en refs/remotes/origin/*, c'est-à-dire de garder la même partie correspondant, en changeant le nom de la branche (refs/heads/) en un nom de branche de suivi du distant (refs/remotes/, spécifiquement, refs/remotes/origin/). C'est grâce à cette refspec que les branches de origin'deviennent vos branches de suivi à distance pour origin`` distant. Le nom de la branche devient le nom de la branche de suivi à distance, avec le nom du distant, dans ce casorigin, inclus. Le signe plus+devant la refspec active l'option "force&quot ;, c'est-à-dire que votre branche de suivi à distance sera mise à jour pour correspondre au nom de la branche distante, peu importe ce qu'il faut faire pour qu'elle corresponde. (Sans le+`, les mises à jour de branches sont limitées aux changements de type "fast forward&quot ; et les mises à jour de balises sont simplement ignorées depuis la version 1.8.2 de Git environ - avant cela, les mêmes règles de fast-forward s'appliquaient).

Balises

Mais qu'en est-il des balises ? Il n'y a pas de spécification de référence pour eux, du moins, pas par défaut. Vous pouvez en définir une, auquel cas la forme de la spécification de référence vous appartient ; ou vous pouvez lancer git fetch --tags. Utiliser --tags a pour effet d'ajouter refs/tags/*:refs/tags/* à la spécification de référence, c'est à dire, il apporte toutes les balises (mais ne met pas à jour votre balise si vous avez déjà une balise avec ce nom, peu importe ce que dit la balise du distant Edit, Jan 2017 : à partir de Git 2.10, les tests montrent que --tags met à jour de force vos balises à partir des balises distantes's, comme si la refspec lisait +refs/tags/*:refs/tags/* ; il peut s'agir d'une différence de comportement par rapport à une version antérieure de Git). Notez qu'il n'y a pas de changement de nom ici : si la version distante origin a le tag xyzzy, et que vous ne l'avez pas, et que vous git fetch origin "refs/tags/*:refs/tags/*", vous aurez refs/tags/xyzzy ajouté à votre dépôt (pointant sur le même commit que sur la version distante). Si vous utilisez +refs/tags/*:refs/tags/*, votre balise xyzzy, si vous en avez une, est remplacée par celle de origin. En d'autres termes, le drapeau de force + sur une spécification de référence signifie "remplacer la valeur de ma référence par celle que mon Git obtient de son Git&quot ;.

Balises automatiques lors de la récupération des données

Pour des raisons historiques,3 si vous n'utilisez ni l'option --tags ni l'option --no-tags, git fetch prend des mesures spéciales. Rappelez-vous que nous avons dit plus haut que le distant commence par afficher à votre Git local toutes ses références, que votre Git local veuille les voir ou non.4 Votre Git prend note de toutes les balises qu'il voit à ce stade. Ensuite, lorsqu'il commence à télécharger les objets commit dont il a besoin pour gérer ce qu'il récupère, si l'un de ces commits a le même ID que l'une de ces étiquettes, git ajoutera cette étiquette - ou ces étiquettes, si plusieurs étiquettes ont cet ID - à votre dépôt ; Edit, Jan 2017 : les tests montrent que le comportement dans Git 2.10 est maintenant : Si leur Git fournit une balise nommée T, et vous n'avez pas de balise nommée T, et l'ID de commit associé à T est un ancêtre d'une de leurs branches que votre git fetch examine, votre Git ajoute T à vos balises avec ou sans --tags. En ajoutant --tags, votre Git obtient tous leurs tags, et force également la mise à jour.

En résumé

Vous devrez peut-être utiliser git fetch --tags pour obtenir leurs tags. Si leurs noms de balises entrent en conflit avec vos noms de balises existants, vous pourrez (selon la version de Git) même avoir à supprimer (ou renommer) certaines de vos balises, et ensuite lancer git fetch --tags, pour obtenir leurs balises. Puisque les balises, contrairement aux branches distantes, n'ont pas de renommage automatique, vos noms de balises doivent correspondre à leurs noms de balises, ce qui explique pourquoi vous pouvez avoir des problèmes de conflits. Dans la plupart des cas normaux, cependant, un simple git fetch fera le travail, apportant leurs commits et leurs tags correspondants, et puisqu'ils - qui qu'ils soient - tagueront les commits au moment où ils les publieront, vous resterez au courant de leurs tags. Si vous ne créez pas vos propres étiquettes, et que vous ne mélangez pas leur dépôt et d'autres dépôts (via plusieurs remotes), vous n'aurez pas non plus de collisions de noms d'étiquettes, et vous n'aurez donc pas à vous embêter à supprimer ou renommer des étiquettes pour obtenir leurs étiquettes.

Quand vous avez besoin de noms qualifiés

J'ai mentionné plus haut que vous pouvez omettre refs/ presque toujours, et refs/heads/ et refs/tags/ et ainsi de suite la plupart du temps. Mais quand ne pouvez-vous pas le faire ? La réponse complète (ou presque complète en tout cas) se trouve dans [la documentation gitrevisions] (https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html). Git va résoudre un nom en un ID de commit en utilisant la séquence en six étapes donnée dans le lien. Curieusement, les tags prennent le pas sur les branches : s'il y a un tag xyzzy et une branche xyzzy, et qu'ils pointent sur des commits différents, alors :

git rev-parse xyzzy

vous donnera l'identifiant vers lequel le tag pointe. Cependant - et c'est ce qui manque à gitrevisions - git checkout préfère les noms de branches, donc git checkout xyzzy vous mettra sur la branche, sans tenir compte du tag. En cas d'ambiguïté, vous pouvez presque toujours épeler le nom de la ref en utilisant son nom complet, refs/heads/xyzzy ou refs/tags/xyzzy. (Notez que cela fonctionne avec git checkout, mais d'une manière peut-être inattendue : git checkout refs/heads/xyzzy provoque un detached-HEAD checkout plutôt qu'un branch checkout. C'est pourquoi vous devez simplement noter que git checkout utilisera d'abord le nom court comme nom de branche : c'est ainsi que vous pourrez extraire la branche xyzzy même si le tag xyzzy existe. Si vous voulez extraire le tag, vous pouvez utiliser refs/tags/xyzzy). Comme (comme le note gitrevisions) Git essaiera refs/name, vous pouvez aussi simplement écrire tags/xyzzy pour identifier le commit tagué xyzzy. (Si quelqu'un a réussi à écrire une référence valide nommée xyzzy dans $GIT_DIR, cependant, cela se résoudra en $GIT_DIR/xyzzy. Mais normalement, seuls les différents noms *HEAD devraient se trouver dans $GIT_DIR).

1Ok, ok, "pas juste pour être pédant&quot ;. :-) 2Certains diraient "très peu utile&quot ;, et j'aurais tendance à être d'accord, en fait. 3Fondamentalement, git fetch, et tout le concept de remotes et refspecs, a été un peu un ajout tardif à Git, se produisant autour de l'époque de Git 1.5. Avant cela, il n'y avait que quelques cas spéciaux ad-hoc, et le tag-fetch était l'un d'entre eux, il a donc été intégré par un code spécial. 4Si cela peut vous aider, considérez le Git distant comme un flasher, au sens argotique du terme.

Pour obtenir le code de balise spécifique, essayez de créer une nouvelle branche et de récupérer le code de balise dans celle-ci. Je l'ai fait avec la commande : $git checkout -b newBranchName tagName.