Comment renommez-vous un tag Git?

Aujourd’hui, je parcourais les journaux pour un projet et je me suis rendu compte qu’il y a quelque temps, je prenais un nom de tag. Est-il possible de renommer le tag? Google n’a rien trouvé d’utile.

Je me rends compte que je pourrais vérifier la version étiquetée et faire un nouveau tag, j’ai même essayé ça. Mais cela semble créer un object tag qui n’est pas tout à fait correct. Pour un,

git tag -l 

le liste dans le désordre par rapport à toutes les autres balises. Je n’ai aucune idée si cela est significatif, mais cela m’amène à croire que le nouvel object tag n’est pas tout à fait ce que je veux. Je peux vivre avec ça, parce que je me soucie vraiment du fait que le nom du tag corresponde à la documentation, mais je préfère le faire “correctement”, en supposant qu’il ya une bonne façon de le faire.

Voici comment je renomme une balise old en new :

 git tag new old git tag -d old git push origin :refs/tags/old git push --tags 

Le deux-points dans la commande push supprime la balise du référentiel distant. Si vous ne le faites pas, Git créera l’ancien tag sur votre machine lorsque vous tirez.

Enfin, assurez-vous que les autres utilisateurs suppriment la balise supprimée. Veuillez leur dire (collègues) d’exécuter la commande suivante:

 git pull --prune --tags 

La question initiale était de savoir comment renommer une balise, ce qui est facile: créez d’abord NEW en tant qu’alias de OLD: git tag NEW OLD puis supprimez OLD: git tag -d OLD .

La citation concernant “la voie Git” et (in) sanity est hors-base, car il s’agit de préserver un nom de balise, mais de le faire référence à un état de référentiel différent.

En plus des autres réponses:

Vous devez d’abord créer un alias de l’ ancien nom de tag, en pointant sur le commit d’origine:

 git tag new old^{} 

Ensuite, vous devez supprimer l’ancien:

 git tag -d old 

Supprimez ensuite le tag sur votre ou vos sites distants:

 # Check your remote sources: git remote -v # The argument (3rd) is your remote location, # the one you can see with `git remote`. In this example: `origin` git push origin :refs/tags/old 

Enfin, vous devez append votre nouvelle balise à l’emplacement distant. Jusqu’à ce que vous ayez fait cela, les nouvelles balises ne seront pas ajoutées:

 git push origin --tags 

Répétez cette opération pour chaque site distant.

Soyez conscient des implications d’un changement de Tag Git sur les consommateurs d’un package!

Si elle est publiée, vous ne pouvez pas la supprimer (sans risquer d’être goudronnée et mise en drapeau). La «manière Git» est de faire:

La chose saine Admettez simplement que vous avez foiré et utilisez un autre nom. D’autres ont déjà vu un nom de balise, et si vous gardez le même nom, il se peut que deux personnes aient toutes deux la “version X”, mais elles ont en fait des “X” différents. Alors, appelez-le simplement “X.1” et terminez-le.

Alternativement,

La chose folle Vous voulez vraiment appeler la nouvelle version “X” même si d’autres ont déjà vu l’ancienne. Donc, utilisez simplement git-tag -f, comme si vous n’aviez pas déjà publié l’ancien.

C’est tellement fou parce que:

Git (et il ne devrait pas) changer les tags derrière les utilisateurs. Donc, si quelqu’un a déjà le vieux tag, faire un git-pull sur votre arbre ne devrait pas simplement lui faire écraser l’ancien.

Si quelqu’un a reçu une balise de dégagement de votre part, vous ne pouvez pas simplement modifier la balise en mettant à jour votre propre balise. Il s’agit d’un problème de sécurité majeur, car les utilisateurs DOIVENT faire confiance à leurs noms de tags. Si vous voulez vraiment faire la chose folle, vous devez simplement vous en rendre compte et dire aux gens que vous avez tout gâché.

Toute la courtoisie des pages de manuel .

Cette page wiki a cet intéressant one-liner, qui nous rappelle que nous pouvons pousser plusieurs références :

 git push origin : : && git tag -d  

et demander aux autres cloneurs de faire git pull --prune --tags

Donc l’idée est de pousser:

  • pour chaque commits référencés par >: : ,
  • la suppression de :

Voir à titre d'exemple " Modifier la convention de dénomination des balises à l'intérieur d'un référentiel git? ".

Comme ajout aux autres réponses, j’ai ajouté un alias pour tout faire en une seule étape, avec une sensation de commande de déplacement * nix plus familière. L’argument 1 est l’ancien nom de tag, l’argument 2 est le nouveau nom de tag.

 [alias] renameTag = "!sh -c 'set -e;git tag $2 $1; git tag -d $1;git push origin :refs/tags/$1;git push --tags' -" 

Usage:

 git renametag old new 

Pour les aventuriers, cela peut se faire en une seule commande:

 mv .git/refs/tags/OLD .git/refs/tags/NEW 

La partie facile renomme les balises locales. La partie la plus difficile est la partie distante. L’idée derrière cette astuce est de dupliquer l’ancien tag / twig sur un nouveau et supprimer l’ancien, sans passer à la caisse.

Renommer les balises distantes / twig distante → conversion des balises: (remarque :refs/tags/ )

 git push  :refs/tags/ : 

Renommer la twig distante / Balise distante → Conversion de twig: (Remarque :refs/heads/ )

 git push  :refs/heads/ : 

Sortie en renommant une balise distante:

 D:\git.repo>git push gitlab App%2012.1%20v12.1.0.23:refs/tags/App_12.1_v12.1.0.23 :App%2012.1%20v12.1.0.23 Total 0 (delta 0), reused 0 (delta 0) To https://gitlab.server/project/repository.git - [deleted] App%2012.1%20v12.1.0.23 * [new tag] App%2012.1%20v12.1.0.23 -> App_12.1_v12.1.0.23 

Indépendamment des problèmes liés au repoussage des balises et au changement de nom des balises déjà poussées, si la balise à renommer est une balise annotée , vous pouvez d’abord la copier à l’aide de la ligne de commande suivante:

 git tag -a -m "`git cat-file -p old_tag | tail -n +6`" new_tag old_tag^{} 

Ensuite, il vous suffit de supprimer l’ancienne balise:

 git tag -d old_tag 

J’ai trouvé cette ligne de commande grâce aux deux réponses suivantes:

Modifier:
Ayant rencontré des problèmes lors de l’utilisation de la synchronisation automatique des balises définissant fetch.pruneTags=true (comme décrit dans https://stackoverflow.com/a/49215190/7009806 ), je suggère personnellement de copier d’ abord la nouvelle balise sur le serveur, puis de supprimer l’ancienne. un. De cette façon, la nouvelle balise ne sera pas supprimée de manière aléatoire lors de la suppression de l’ancienne balise et une synchronisation des balises souhaiterait supprimer la nouvelle balise qui n’est pas encore sur le serveur . Donc, par exemple, tous ensemble nous obtenons:

 git tag -a -m "`git cat-file -p old_tag | tail -n +6`" new_tag old_tag^{} git push --tags git tag -d old_tag git push origin :refs/tags/old_tag