Aujourd'hui, je parcourais les journaux pour trouver un projet et je me suis rendu compte que j'avais déjà identifié un nom de balise il y a quelque temps. Est-il possible de renommer le tag? Google n'a rien révélé d'utile.
Je me suis rendu compte que je pouvais consulter la version étiquetée et créer une nouvelle étiquette. J'ai même essayé. Mais cela semble créer un objet tag qui n’a pas tout à fait raison. Pour un,
git tag -l
la liste dans le désordre par rapport à toutes les autres balises. Je ne sais pas si c'est important, mais cela me porte à croire que le nouvel objet tag n'est pas tout à fait ce que je veux. Je peux vivre avec cela, parce que je tiens uniquement à ce que le nom de l'étiquette corresponde à la documentation, mais je préfère le faire "correctement", en supposant qu'il existe 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
Les deux points de la commande Push suppriment la balise du référentiel distant. Si vous ne le faites pas, Git créera l'ancienne balise sur votre machine lorsque vous tirerez.
Enfin, assurez-vous que les autres utilisateurs suppriment la balise supprimée. S'il vous plaît dites-leur (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 simple: commencez par créer NEW avec un alias OLD: git tag NEW OLD
, puis supprimez OLD: git tag -d OLD
.
La citation concernant "la manière Git" et la (santé) sens est erronée, car il est question de conserver 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 construire un alias du nom de la balise ancien , en pointant au commit d'origine:
git tag new old^{}
Ensuite, vous devez supprimer l'ancien localement :
git tag -d old
Supprimez ensuite la balise 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 ajouter votre nouvelle balise à l'emplacement distant. Tant que vous n’avez pas fait cela, les nouvelles balises ne seront pas ajoutées:
git Push Origin --tags
Itérer ceci pour chaque emplacement distant.
Soyez conscient des implications qu'un changement de balise Git a pour les utilisateurs d'un package!
Si c'est publié, vous ne pouvez pas le supprimer (sans risquer d'être goudronné et mis en drapeau, c'est-à-dire). La "façon Git" consiste à faire:
La chose saine. Admettez que vous avez foiré et utilisez un autre nom. D'autres ont déjà vu un nom de balise, et si vous conservez le même nom, vous pouvez être dans la situation où deux personnes possèdent la "version X", mais elles ont en fait des "X" différents. Appelez-le simplement "X.1" et finissez-en.
Alternativement
La chose folle. Vous voulez vraiment appeler la nouvelle version "X" aussi, même si d’autres ont déjà vu l’ancienne. Utilisez donc à nouveau git-tag -f, comme si vous n'aviez pas déjà publié l'ancien.
C'est tellement fou parce que:
Git ne change pas (et ne devrait pas) changer les tags derrière les utilisateurs. Donc, si quelqu'un a déjà reçu l'ancienne balise, faire un git-pull sur votre arbre ne doit pas simplement leur faire écraser l'ancienne.
Si quelqu'un a reçu une étiquette de version de votre part, vous ne pouvez pas simplement la modifier en mettant à jour la vôtre. C'est un gros problème de sécurité, dans la mesure où les personnes DOIVENT pouvoir faire confiance à leurs noms de balises. Si vous voulez vraiment faire ce qui est fou, vous devez vous en méfier et dire aux gens que vous vous êtes trompés.
Toute la courtoisie du 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 <refs/tags/old-tag>:<refs/tags/new-tag> :<refs/tags/old-tag> && git tag -d <old-tag>
et demandez aux autres cloneurs de faire
git pull --Prune --tags
L'idée est donc de pousser:
<new-tag>
pour chaque commits référencé par <old-tag
>: <refs/tags/old-tag>:<refs/tags/new-tag>
,<old-tag>
: :<refs/tags/old-tag>
Voir à titre d'exemple " Changer la convention de nommage des balises dans un dépôt git? ".
En plus des autres réponses, j’ai ajouté un alias pour tout faire en une seule étape, avec une sensation de commande de mouvement plus familière * nix. L'argument 1 est l'ancien nom de balise, l'argument 2 est le nouveau nom de balise.
[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 plus aventureux, cela peut être fait en une seule commande:
mv .git/refs/tags/OLD .git/refs/tags/NEW
Quels que soient les problèmes liés au repoussage et au changement de nom des balises qui ont déjà été poussés, dans le cas où le libellé à renommer est un annoté , vous pouvez d’abord le copier grâce au single suivant. ligne de commande:
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:
Après avoir rencontré des problèmes lors de l’utilisation de la synchronisation automatique des balises dans le paramètre fetch.pruneTags=true
(comme décrit dans https://stackoverflow.com/a/49215190/7009806 ), je suggère personnellement de d’abord copiez la nouvelle balise sur le serveur et puis supprimez l’ancienne. 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 voudrait supprimer la nouvelle balise qui n'est pas encore sur le serveur . Ainsi, 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
Suivez l’approche en 3 étapes pour un ou plusieurs tags.
command: git rev-parse <tag name>
example: git rev-parse v0.1.0-Demo
example output: db57b63b77a6bae3e725cbb9025d65fa1eabcde
command: git tag -d <tag name>
example: git tag -d v0.1.0-Demo
example output: Deleted tag 'v0.1.0-Demo' (was abcde)
command: git tag -a <tag name> -m "appropriate message" <commit id>
example: git tag -a v0.1.0-full -m "renamed from v0.1.0-Demo" db57b63b77a6bae3e725cbb9025d65fa1eabcde
example output: Nothing or basically <No error>
Une fois que le git local est prêt avec le changement de nom de balise, ces modifications peuvent être reportées à l'origine pour que d'autres puissent les prendre.
La partie facile est de renommer les tags locaux. La partie la plus difficile est celle qui est éloignée. L'idée derrière cette astuce est de dupliquer l'ancienne balise/branche vers une nouvelle et de supprimer l'ancienne, sans passer à la caisse.
renommer une étiquette distante/branche distante → conversion d'une étiquette: (Avis: :refs/tags/
)
git Push <remote_name> <old_branch_or_tag>:refs/tags/<new_tag> :<old_branch_or_tag>
Renommage de branche distante/Balise distante → conversion de branche: (Remarque: :refs/heads/
)
git Push <remote_name> <old_branch_or_tag>:refs/heads/<new_branch> :<old_branch_or_tag>
Sortie renommer 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