Qu'est-ce que git tag?, Comment créer des tags et comment utiliser les tags git distants?
quand j'achète une balise git à distance, utilisez une commande comme ceci:
git checkout -b local_branch_name Origin/remote_tag_name
J'ai une erreur comme ça:
error: pathspec `Origin/remote_tag_name` did not match any file(s) known to git.
Je peux trouver remote_tag_name lorsque j'utilise la commande git tag.
Commençons par expliquer ce qu'est un tag dans git
Une balise est utilisée pour étiqueter et marquer un commit spécifique dans l'historique.
Il est généralement utilisé pour marquer les points de libération (par exemple. V1.0, etc.).Bien qu'une étiquette puisse ressembler à une branche, , elle ne change toutefois pas .
Il pointe directement sur un commit spécifique dans le histoire.
Vous ne pourrez pas extraire les balises si elles ne se trouvent pas localement dans votre référentiel; vous devez donc commencer par fetch les balises dans votre référentiel local.
Tout 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
Ensuite, vérifiez la balise en exécutant
git checkout tags/<tag_name> -b <branch_name>
Au lieu de Origin, utilisez le préfixe tags/.
Dans cet exemple, vous avez 2 balises version 1.0 et 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 ...
Tout ce qui précède fera la même chose puisque tag est seulement un pointeur sur un commit donné.
Origine: https://backlog.com/git-tutorial/img/post/stepup/capture_stepup4_1_1.png
Comment voir la liste de tous les tags?
# list all tags
git tag
# list all tags with given pattern ex: v-
git tag --list 'v-*'
Comment créer des tags?
Il y a 2 façons de créer un tag:
# normal tag
git tag
# annotated tag
git tag -a
La différence entre les 2 est que, lors de la création d'une balise annotée, vous pouvez ajouter des métadonnées comme dans un commit git:
nom, email, date, commentaire et signature
Comment supprimer des tags?
# delete any given tag
git tag -d <tag name>
# Don't forget to remove the deleted tag form the server with Push tags
Comment cloner une balise spécifique?
Pour récupérer le contenu d'une balise donnée, vous pouvez utiliser la commande checkout.
Comme expliqué ci-dessus, les tags sont comme tous les autres commits. Nous pouvons donc utiliser checkout et au lieu d'utiliser SHA-1, il vous suffit de le remplacer 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/<tag> -b <branch>
Option 2:
Utilisation de la commande clone
Depuis que git supporte shallow clone en ajoutant le --branch à la commande de clonage, nous pouvons utiliser le nom de la balise au lieu du nom de la branche. Git sait comment "traduire" le SHA-1 donné en commit correspondant
# Clone a specific tag name using git clone
git clone <url> --branch=<tag_name>
git clone --branch =
--branchpeut également prendre des balises et détache le HEAD à cette validation dans le référentiel résultant.
(Cette réponse a pris un certain temps à écrire, et la réponse de codeWizard est correcte dans son objectif et dans son essence, mais n'est pas tout à fait complète, donc je posterai cela quand même.)
Il n’existe pas de "balise Git distante". Il n'y a que des "tags". Je souligne tout cela pour ne pas être pédant,1 mais parce qu'il y a beaucoup de confusion à ce sujet avec les utilisateurs occasionnels de Git et que la documentation de Git n'est pas très utile.2 aux débutants. (On ne sait pas si la confusion vient de la médiocrité de la documentation, ou de la médiocrité de la documentation, parce que c'est déroutant par nature, ou quoi.)
Il existe des "branches distantes", plus précisément appelées "branches de suivi à distance", mais il convient de noter que ce sont en fait des entités locales. Il n'y a pas de balises distantes, cependant (à moins que vous ne les (ré) inventiez) Il n'y a que des balises locales, vous devez donc obtenir la balise localement pour pouvoir l'utiliser.
La forme générale des noms de commits spécifiques (que Git appelle fait référence à - est une chaîne commençant par refs/. Une chaîne commençant par refs/heads/ nomme une branche; une chaîne commençant par refs/remotes/ nomme une branche de suivi à distance; et une chaîne commençant par refs/tags/ nomme une balise. Le nom refs/stash est la référence de dissimulation (utilisée par git stash; notez l'absence de barre oblique finale).
Il existe des noms de cas spéciaux inhabituels qui ne commencent pas par refs/: HEAD, ORIG_HEAD, MERGE_HEAD et CHERRY_PICK_HEAD sont également des noms qui peut faire référence à des commits spécifiques (bien que HEAD contienne normalement le nom d'une branche, c'est-à-dire qu'il contienne ref: refs/heads/branch). Mais en général, les références commencent par refs/.
Une chose que Git fait pour rendre cela déroutant est qu’il vous permet d’omettre le 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 ou à une balise locale. En fait, vous devez omettre refs/heads/ lors de la vérification d'une branche locale! Vous pouvez le faire chaque fois que le résultat est sans ambiguïté ou, comme nous venons de le dire, lorsque vous devez le faire (pour git checkout branch).
Il est vrai que les références existent non seulement dans votre propre référentiel, mais également dans des référentiels distants. Cependant, Git ne vous donne accès aux références d’un référentiel distant qu’à des moments très spécifiques: à savoir, lors des opérations fetch et Push. Vous pouvez également utiliser git ls-remote ou git remote show pour les voir, mais fetch et Push sont les points de contact les plus intéressants.
Réfspecs
Au cours de fetch et Push, Git utilise des chaînes qu'il appelle refspecs pour transférer des références entre le référentiel local et distant. C'est donc à ces moments, et via refspecs, que deux référentiels Git peuvent être synchronisés l'un avec l'autre. Une fois vos noms synchronisés, vous pouvez utiliser le même nom que celui utilisé par quelqu'un de la télécommande. Il y a cependant une magie spéciale ici sur fetch, qui affecte à la fois les noms de branche et les noms de balises.
Vous devriez penser à git fetch comme à un Git qui appelle (ou peut-être un message texte) un autre Git - le "distant" - et s'entretient avec lui. Au début de cette conversation, la télécommande répertorie toutes ses références: tout ce qui se trouve dans refs/heads/ et tout ce qui se trouve dans refs/tags/, ainsi que toutes les autres références dont il dispose. Votre Git les scanne et (selon l’habituel refspec) renomme leurs branches.
Jetons un coup d'œil à la référence normale de la télécommande nommée Origin:
$ git config --get-all remote.Origin.fetch
+refs/heads/*:refs/remotes/Origin/*
$
Cette refspec indique à votre Git de prendre chaque nom correspondant à refs/heads/* (c'est-à-dire chaque branche de la télécommande) et de changer son nom en refs/remotes/Origin/*, c'est-à-dire de garder la partie correspondante identique, en modifiant le nom de la branche (refs/heads/) à un nom de branche de suivi à distance (refs/remotes/, en particulier refs/remotes/Origin/).
C’est par l’intermédiaire de cette référence que les branches de Origin deviennent vos branches de suivi à distance pour Origin à distance. Le nom de la branche devient le nom de la branche de suivi à distance, avec le nom de la télécommande, dans ce cas Origin, inclus. Le signe plus + situé à l’avant de la référence spécifie l’option "force", c’est-à-dire que votre branche de suivi à distance sera mise à jour pour correspondre au nom de la branche distante, quelle que soit sa correspondance. (Sans le +, les mises à jour de branche sont limitées aux modifications "d'avance rapide" et les mises à jour de balises sont simplement ignorées à partir de la version 1.8.2 de Git, alors qu'avant, les mêmes règles d'avance rapide étaient appliquées.)
Mots clés
Mais qu'en est-il des balises? Il n'y a pas de référence pour eux - du moins, pas par défaut. Vous pouvez en définir un, auquel cas la forme du refspec dépend de vous; ou vous pouvez exécuter git fetch --tags. Utiliser --tags a pour effet d’ajouter refs/tags/*:refs/tags/* à la référence, c’est-à-dire qu’il entraîne toutes les balises (mais ne met pas à jour votre balise si vous avez déjà une balise portant ce nom, , quelle que soit la signification de la balise de la télécommande Edit, Jan 2017: depuis Git 2.10, les tests montrent que --tags met à jour de force vos balises à partir des balises de la télécommande, comme si le refspec lisait +refs/tags/*:refs/tags/*; cela peut être une différence de comportement par rapport à une version antérieure de Git).
Notez qu’il n’ya pas de renommage ici: si Origin à distance a la balise xyzzy, et vous, et git fetch Origin "refs/tags/*:refs/tags/*", vous obtenez refs/tags/xyzzy ajouté à votre référentiel (pointant au même commit que sur la télécommande). Si vous utilisez +refs/tags/*:refs/tags/* alors votre balise xyzzy, si vous en avez une, est remplacée par celle de Origin. Autrement dit, l'indicateur de force + sur un refspec signifie "remplace la valeur de ma référence par celle que mon Git obtient de leur Git".
Balises Automagic pendant l'extraction
Pour des raisons historiques,3 Si vous n'utilisez ni l'option --tags ni l'option --no-tags, git fetch effectue une action spéciale. Rappelez-vous que nous avons dit plus haut que la télécommande commence par afficher sur 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, au moment où il commence à télécharger les objets de validation dont il a besoin pour gérer tout ce qu’il va extraire, si l’une de ces validations a le même identifiant que l’une de ces balises, git ajoutera cette votre référentiel.
Edit, Jan 2017: les tests montrent que le comportement dans Git 2.10 est le suivant: Si leur Git fournit une balise nommée T, et vous ne possédez pas de balise nommée T, et l'ID de validation associé à T est un ancêtre de l'une de leurs branches que votre git fetch examine, votre Git ajoute T à vos balises avec ou sans --tags. Ajouter --tags force votre Git à obtenir toutes les balises et à forcer la mise à jour.
Ligne de fond
Vous devrez peut-être utiliser git fetch --tags pour obtenir leurs balises. Si leurs noms de tags sont en conflit avec vos noms de tags existants, vous pouvez (selon la version de Git) même supprimer (ou renommer) certains de vos tags, puis exécutez git fetch --tags, pour obtenir leurs balises. Etant donné que les étiquettes, contrairement aux branches distantes, n'ont pas de renommage automatique, vos noms d'étiquette doivent correspondre à leurs noms, raison pour laquelle vous pouvez avoir des problèmes de conflits.
Dans la plupart des cas normaux, cependant, un simple git fetch fera le travail, en rapportant leurs commits et leurs balises correspondantes, et depuis: peu importe qui ils sont, les tags seront validés au moment où ils les publieront, vous suivrez leurs tags. Si vous ne créez pas vos propres balises, ni ne mélangez leur référentiel et d'autres référentiels (via plusieurs télécommandes), vous ne rencontrerez aucune collision de noms de balises, vous n'aurez donc pas à vous soucier de supprimer ou de renommer des balises obtenir leurs tags.
Quand vous avez besoin de noms qualifiés
J'ai mentionné ci-dessus que vous pouvez omettre presque toujours refs/, et refs/heads/ et refs/tags/ et ainsi de suite la plupart du temps. Mais quand ne peut pas vous?
La réponse complète (ou presque complète de toute façon) est dans la documentation gitrevisions . Git résoudra un nom en identifiant de validation en utilisant la séquence en six étapes indiquée dans le lien. Curieusement, les balises remplacent les branches: s'il existe une balise xyzzy et une branche xyzzy, et qu'elles pointent vers des commits différents, alors:
git rev-parse xyzzy
vous donnera l'ID sur lequel pointe la balise. Cependant — et c'est ce qui manque à gitrevisions — git checkout préfère les noms de branche, donc git checkout xyzzy vous mettra sur la branche, sans tenir compte de la balise.
En cas d'ambiguïté, vous pouvez presque toujours épeler le nom de la référence en utilisant son nom complet, refs/heads/xyzzy ou refs/tags/xyzzy. (Notez que cela fonctionne avec git checkout, mais de manière peut-être inattendue: git checkout refs/heads/xyzzy provoque plutôt une extraction de type HEAD détaché. C’est pourquoi vous devez simplement noter que git checkout utilisera d’abord le nom abrégé comme nom de branche: c’est ainsi que vous extrayez la branche xyzzy même si la balise xyzzy existe. Si vous voulez extraire la balise, vous pouvez utiliser refs/tags/xyzzy.)
Parce que (comme gitrevisions notes), Git essaiera refs/name, vous pouvez aussi simplement écrire tags/xyzzy pour identifier la validation marquée xyzzy. (Si quelqu'un a réussi à écrire une référence valide nommée xyzzy dans $GIT_DIR, le problème sera résolu comme $GIT_DIR/xyzzy. Mais normalement, seuls les différents noms *HEAD doivent figurer dans $GIT_DIR.)
1D'accord, d'accord, "ne pas seulement être pédant". :-)
2Certains diraient "très peu utile", et j'ai tendance à être d'accord, en fait.
3Fondamentalement, git fetch, ainsi que le concept de télécommandes et de références, était un ajout tardif à Git, qui a eu lieu à l’époque de Git 1.5. Auparavant, il n'y avait que quelques cas spéciaux ad-hoc, et l'extraction de balises en était un, elle a donc été maintenue grâce à un code spécial.
4Si cela vous aide, considérez la télécommande Git comme un clignotant , dans le sens de l'argot.
Pour obtenir le code de balise spécifique, essayez de créer une nouvelle branche et ajoutez-y le code de balise. Je l'ai fait par commande: $git checkout -b newBranchName tagName