web-dev-qa-db-fra.com

Déplacer le tag un commit en avant

J'ai un référentiel avec une seule branche (master). Je suis le seul contributeur à mon repo.

J'ai récemment ajouté un tag, à la fois localement et poussé vers GitHub. Après avoir fait ce que je pensais être le dernier commit nécessaire, mais maintenant je me rends compte que j'aurais dû faire un autre changement/commit.

Donc ce que j'ai c'est:

commit 124
commit 125
commit 126 <-- tag v1.0
commit 127

et je veux déplacer le v1.0 tag au prochain commit, c'est-à-dire: 127, à la fois localement et dans GitHub.

Comment puis je faire ça?

gitgithubversionversioningcommit
54
Gabriel

Avez-vous déjà visité un club de lecture où les membres n'utilisent pas tous la même édition du "livre de la semaine"? C'est un cauchemar, non? Le déplacement d'une balise vous mettrait essentiellement dans la même situation.

Si vous considérez votre référentiel comme un livre décrivant les progrès de votre projet, vous pouvez considérer une balise comme un en-tête de chapitre .

enter image description here

Déplacer un tag vers un autre commit après le partager, c'est comme le dire à tous vos copains de club de lecture

Vous savez quoi, les gars? L'édition du livre que nous avons tous utilisé jusqu'à présent est désormais obsolète, car j'ai uniquement décrété que le chapitre 8 devrait maintenant commencer, non pas à la page 126, mais à la page 128.

Pas bon. Le déplacement d'une balise est une forme de réécriture de l'historique, et vous ne devez pas réécrire l'historique qui a été partagé. C'est le moyen le plus sûr de faire chier vos collaborateurs. En plus, vous écrivez

Je suis le seul contributeur à mon repo [...]

Cela peut être vrai pour l'instant, mais si d'autres personnes que vous ont accès à votre référentiel GitHub (par exemple s'il est public), certaines d'entre elles l'ont peut-être déjà bifurqué ou cloné (bien qu'il existe un way to savoir), et vous courez le risque de les énerver si vous réécrivez l'histoire.

Si vous êtes sûr à 100% que vous souhaitez déplacer cette balise, Git vous permet de le faire. Ici, vous pouvez utiliser

git tag --force v1.0 <ID-of-commit-127>

puis vous devrez forcer Push cette balise, en utilisant

git Push --force --tags

Mais encore une fois, réfléchissez-y à deux fois avant d'aller de l'avant ...

Addendum (2018/09/26)

Je ressens le besoin de revoir ma réponse ...

Au fil des ans, certaines personnes se sont opposées dans les commentaires à mon injonction de ne pas déplacer une étiquette déjà publiée. Bien sûr, ce conseil est plus contextuel qu'universel; Je ne doute pas qu'il existe de bonnes raisons de déplacer une balise publiée. Cependant, je reste fermement convaincu que, en règle générale, la décision de déplacer une étiquette publiée doit être prise délibérément et avec une extrême prudence.

Un exemple récent me vient à l'esprit. Go 1.11 a ajouté un support expérimental pour un système de modules qui s'appuie fortement sur les balises Git pour la gestion des versions. Le déplacement d'une balise dans un module Go qui a été publié (sur GitHub, par exemple) aurait des conséquences désastreuses.

Ce faisant, vous rompriez le contrat établi entre vous (l'auteur du module) et vos utilisateurs (ceux qui dépendent de votre module), car vous annuleriez les garanties que le système de modules de Go a l'intention de fournir:

Les modules enregistrent des exigences de dépendance précises et créent des versions reproductibles.

C'est un moyen sûr de faire chier les gens.

Cet exemple peut suffire à vous convaincre que, au moins dans certains cas, vous ne devez pas déplacer sans réfléchir les balises publiées. Je repose mon cas.

115
jub0bs

Le déplacement des balises est généralement déconseillé car il peut causer des problèmes en raison de la nature hautement distribuée de Git. Considérer:

  • Vous poussez le tag v1.0 Lors de la validation abcd123
  • Votre copain, appelez-le Fred, va chercher
  • Fred a maintenant une balise v1.0 Locale sur abcd123
  • Vous déplacez la balise v1.0 Pour valider cccc222 Et appuyez sur
  • Les choses suivantes peuvent se produire:
    • Fred récupère, mais la balise v1.0 Sur le serveur ne correspond pas à sa balise v1.0 Locale, donc Fred doit corriger manuellement ce conflit, même s'il n'a rien fait pour le provoquer
    • Fred pousse avec l'option --tags Pour ajouter une nouvelle balise some-tag Qu'il a créée; ce Push est rejeté par le serveur car sa balise v1.0 locale et la balise v1.0 du serveur ne sont pas d'accord

Avec plus de deux développeurs, cela devient beaucoup plus compliqué; si même une seule personne ne prend pas la mesure de mettre à jour sa balise locale, vous pouvez obtenir problème au bout du compte .

Si vous êtes toujours sûr de vouloir déplacer la balise (il s'agit peut-être d'un projet à développeur unique, ou vous êtes par ailleurs sûr que personne n'a récupéré la balise, ou vous êtes prêt à communiquer avec tous les autres développeurs et à vous assurer que ils mettent à jour leurs balises locales), vous pouvez faire quelque chose comme ceci:

git tag -a -f v1.0 <new-commit-hash>
git Push --tags --force

Les autres développeurs doivent être encouragés à supprimer leur copie locale de la balise et à récupérer la nouvelle:

git tag -d v1.0
git fetch --tags
20
Chris

Vous pouvez également supprimer la balise puis la recréer, cela ne nécessite pas de réécriture de l'historique.
(Non Push --force)

Supprimer local et distant

git tag -d <tag_name>
git Push Origin :refs/tags/<tag_name>

Recréer

git tag <tag_name>
git Push --tags
1
Jonas Marty