Edit, 24 novembre 2016: cette réponse est apparemment populaire, j'ajoute donc une note ici. Si vous remplacez une balise sur un serveur central, toute personne qui possède l' ancienne balise (tout clone de ce référentiel de serveur central qui a déjà la balise) peut conserver son ancienne balise . Donc, bien que cela vous indique comment le faire, soyez vraiment sûr de vouloir le faire. Vous devrez demander à toutes les personnes qui ont déjà la «mauvaise» balise de supprimer leur «mauvaise balise» et de la remplacer par la nouvelle «bonne balise».
Les tests dans Git 2.10 / 2.11 montrent que la conservation de l'ancienne balise est le comportement par défaut pour les clients en cours d'exécution git fetch, et la mise à jour est le comportement par défaut pour les clients en cours d'exécution git fetch --tags.
(La réponse originale suit.)
Lorsque vous demandez de pousser des balises, git push --tagsenvoie (avec tous les commits et autres objets nécessaires et toutes les autres mises à jour de référence à partir des paramètres push) à la télécommande une demande de mise à jour du formulaire . (Eh bien, il en envoie autant: un de ceux pour chaque tag.)new-sha1 refs/tags/name
La demande de mise à jour est modifiée par la télécommande pour ajouter une old-sha1(ou encore une pour chaque étiquette), puis livrée aux hooks de pré-réception et / ou de mise à jour (selon les hooks existants sur la télécommande). Ces hooks peuvent décider d'autoriser ou de refuser la création / suppression / mise à jour de la balise.
La old-sha1valeur est le SHA-1 «nul» tout zéros si la balise est en cours de création. Le new-sha1est le SHA-1 nul si la balise est supprimée. Sinon, les deux valeurs SHA-1 sont des valeurs réelles et valides.
Même sans crochet, il y a une sorte de "hook intégré" qui est également exécuté: la télécommande refusera de déplacer une balise à moins que vous n'utilisiez le drapeau "force" (bien que le "hook intégré" soit toujours OK avec les deux "ajouter" et "supprimer"). Le message de rejet que vous voyez provient de ce hook intégré. (Incidemment, ce même hook intégré rejette également les mises à jour de branche qui ne sont pas rapides.) 1
Mais - voici l'une des clés pour comprendre ce qui se passe - l' git pushétape n'a aucune idée si la télécommande a cette balise maintenant, et si oui, quelle valeur SHA-1 elle a. Il dit seulement "voici ma liste complète de balises, avec leurs valeurs SHA-1". La télécommande compare les valeurs et s'il y a des ajouts et / ou des modifications, exécute les hooks sur celles-ci. (Pour les balises identiques, cela ne fait rien du tout. Pour les balises que vous n'avez pas, cela ne fait rien non plus!)
Si vous supprimez la balise localement, pushvotre push ne transfère tout simplement pas la balise. La télécommande suppose qu'aucune modification ne doit être apportée.
Si vous supprimez la balise localement, puis créez-la en pointant vers un nouvel emplacement, alors push, votre push transfère la balise, et la télécommande voit cela comme un changement de balise et rejette la modification, à moins que ce ne soit une poussée forcée.
Ainsi, vous avez deux options:
- faire une poussée forcée, ou
- supprimez l'étiquette de la télécommande.
Cette dernière est possible via git push2 même si la suppression de la balise localement et pushing n'a aucun effet. En supposant que le nom de la télécommande est originet que la balise que vous souhaitez supprimer est dev:
git push origin :refs/tags/dev
Cela demande à la télécommande de supprimer la balise. La présence ou l'absence de la balise devdans votre référentiel local n'est pas pertinente; ce genre de push, avec comme refspec, est une pure suppression.:remoteref
La télécommande peut autoriser ou non la suppression de balises (en fonction des crochets supplémentaires ajoutés). Si cela permet la suppression, alors la balise disparaîtra, et une seconde git push --tags, lorsque vous avez une devbalise locale pointant vers un objet de repo de balises de validation ou annoté, envoyez votre nouvelle devbalise. Sur la télécommande, il y devaura désormais une balise nouvellement créée, donc la télécommande autorisera probablement le push (encore une fois, cela dépend de tout crochet supplémentaire ajouté).
La force-push est plus simple. Si vous voulez être sûr de ne mettre à jour autre chose que la balise, dites simplement git pushde ne pousser que cette refspec:
git push --force origin refs/tags/dev:refs/tags/dev
(note: vous n'en avez pas besoin --tagssi vous poussez explicitement une seule balise ref-spec).
1 Bien sûr, la raison de ce hook intégré est d'aider à appliquer le comportement attendu par les autres utilisateurs de ce même dépôt distant: les branches ne sont pas rembobinées et les balises ne bougent pas. Si vous forcez, vous devez informer les autres utilisateurs que vous faites cela, afin qu'ils puissent y remédier. Notez que "les balises ne bougent pas du tout" est nouvellement appliquée par Git 1.8.2; les versions précédentes permettaient à la balise de "progresser" dans le graphe de validation, un peu comme les noms de branche. Consultez les notes de publication de git 1.8.2 .
2 C'est trivial si vous pouvez vous connecter sur la télécommande. Allez simplement dans le référentiel Git et exécutez git tag -d dev. Notez que dans les deux cas - en supprimant l'étiquette de la télécommande ou en utilisant git pushpour la supprimer - il y a une période pendant laquelle quiconque accède à la télécommande trouvera que l' devétiquette est manquante. (Ils continueront d'avoir leur propre ancienne balise, s'ils l'ont déjà, et ils pourraient même repousser leur ancienne balise avant que vous puissiez pousser la nouvelle.)
