erreur "tag already exists in the remote" après avoir recréé le tag git

Question

J'obtiens l'erreur suivante après avoir exécuté les étapes ci-dessous :

To git@provider.com:username/repo-name.git
 ! [rejected]        dev -> dev (already exists)
error: failed to push some refs to 'git@provider.com:username/repo-name.git'
hint: Updates were rejected because the tag already exists in the remote.

1. Création du référentiel
2. Cloner le repo sur la machine locale.
3. Modifié le fichier README, commité les changements et poussé le commit.
4. Balise créée dev : git tag dev
5. Des tags poussés : git push --tags
6. Modifié le fichier README, commité les changements et poussé le commit.

7. Étiquette supprimée dev il l'a créé à nouveau et a poussé les tags :

   git tag -d dev
   git tag dev
   git push --tags

Pourquoi cela se produit-il ?

Je suis sur Mac. Mes amis qui utilisent Linux (Ubuntu) n'ont pas ce problème. Je sais que je peux utiliser git push --tags -f pour forcer la mise à jour de la balise, mais cela est dangereux (par exemple, réécrire un commit fait par erreur uniquement dans la balise, pas dans la branche).

Answer 1

La raison pour laquelle vous obtenez rejeté est que votre tag a perdu la synchronisation avec la version distante. C'est le même comportement avec les branches.

synchronisation avec la balise de la télécommande via git pull --rebase <repo_url> +refs/tags/<TAG> et après avoir synchronisé, vous devez gérer les conflits . Si vous avez un diftool installé (ex. meld) git mergetool meld utilisez-le pour synchroniser à distance et conserver vos modifications.

La raison pour laquelle vous tirez avec --rebase Le flag est que vous voulez placer votre travail au-dessus de celui de la personne éloignée afin d'éviter d'autres conflits.

Aussi, ce que je ne comprends pas, c'est pourquoi vous supprimez la dev et le recréer ??? Les balises sont utilisées pour spécifier les versions des logiciels ou les jalons. Exemple de balises git v0.1dev , v0.0.1alpha , v2.3-cr (cr - candidate release) et ainsi de suite

---

Une autre façon de résoudre ce problème est d'émettre un git reflog et revenir au moment où vous avez appuyé sur la touche dev sur la télécommande. Copiez le ID de l'engagement y git reset --mixed <commmit_id_from_reflog> De cette façon, vous savez que votre balise était synchronisée avec la télécommande au moment où vous l'avez poussée et aucun conflit ne surviendra.

Answer 2

Dans Windows SourceTree, décochez Push all tags to remotes .

Answer 3

Quelques bonnes réponses ici. En particulier celui de @torek . J'ai pensé ajouter cette solution de contournement avec une petite explication pour ceux qui sont pressés.

Pour résumer, ce qui se passe est que lorsque vous déplacez une balise localement, cela change la balise d'une valeur de commit non nulle à une valeur différente. Cependant, comme git (par défaut) ne permet pas de modifier les balises distantes non nulles, vous ne pouvez pas pousser la modification.

La solution consiste à supprimer la balise (et à supprimer toutes les télécommandes). Créez ensuite la même balise et poussez-la.