Ответ 1

Вы когда-нибудь были в книжном клубе, где не все участники используют одно и то же издание "Книги недели"? Это кошмар, верно? Перемещение тега по сути поставит вас в ту же ситуацию.

Если вы думаете о своем хранилище как о книге, в которой рассказывается о прогрессе в вашем проекте, вы можете рассматривать тег как заголовок главы.

Переместить тег в другой коммит после публикации это все равно, что рассказать всем своим друзьям из книжного клуба

Вы знаете что, ребята? Издание книги, которое мы все использовали до сих пор, устарело, потому что я единолично постановил, что глава 8 теперь должна начаться не на странице 126, а на странице 128.

Нехорошо. Перемещение тега - это форма переписывания истории, и вы не должны переписывать историю, которой поделились. Это самый верный способ разозлить ваших сотрудников. Кроме того, ты пишешь

Я единственный участник моего репо [...]

На данный момент это может быть правдой, но если другие пользователи, кроме вас, имеют доступ к вашему репозиторию GitHub (например, если он общедоступный), некоторые из них, возможно, уже раздвоили или клонировали его (хотя есть способ выяснить это), и вы запускаете риск разозлить их, если переписать историю.

Если вы на 100% уверены, что хотите переместить этот тег в любом случае, Git позволит вам это сделать. Здесь вы можете использовать

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

и тогда вам придется принудительно нажать на этот тег, используя

git push --force --tags

Но опять же, подумайте дважды, прежде чем идти вперед...

Приложение (2018/09/26)

Я чувствую необходимость пересмотреть мой ответ...

На протяжении многих лет некоторые люди в комментариях к моему запрету возражали не перемещать уже опубликованный тег. Конечно, этот совет скорее контекстуальный, чем универсальный; Я не сомневаюсь, что есть хорошие причины для перемещения опубликованного тега. Однако я твердо убежден в том, что, как правило, решение о перемещении опубликованного тега должно приниматься осознанно и с особой тщательностью.

Один недавний пример приходит на ум. В Go 1.11 добавлена экспериментальная поддержка модульной системы, которая в значительной степени опирается на теги Git для управления версиями. Перемещение тега в опубликованном модуле Go (скажем, на GitHub) будет иметь катастрофические последствия.

Таким образом, вы нарушите договор, заключенный между вами (автором модуля) и вашими пользователями (теми, кто зависит от вашего модуля), потому что вы отрицаете гарантии, которые система модулей Go намеревается предоставить:

Модули записывают точные требования к зависимостям и создают воспроизводимые сборки.

Это верный способ разозлить людей.

Этого примера может быть достаточно, чтобы убедить вас, что, по крайней мере, в некоторых случаях вы не должны бездумно перемещать опубликованные теги. Я считаю так.

Ответ 2

Перемещение тегов, как правило, не рекомендуется, так как это может вызвать проблемы из-за высокой распространенности Git. Рассматривать:

• Вы нажимаете тег v1.0 на abcd123
• Твой приятель, зови его Фред, выбирает
• Фред теперь имеет локальный тег v1.0 на abcd123
• Вы перемещаете тег v1.0 для фиксации cccc222 и нажимаете
• Может произойти следующее:
  • Фред выбирает, но тег v1.0 на сервере не совпадает с его локальным тегом v1.0, поэтому Фред должен вручную исправить этот конфликт, даже если он не сделал ничего, чтобы вызвать его
  • Фред --tags опцию --tags чтобы добавить новый тег some-tag который он создал; этот запрос отклонен сервером, потому что его локальный тег v1.0 тег server v1.0 совпадают

С более чем двумя разработчиками это становится намного сложнее; если хотя бы один человек не предпримет шаги по обновлению своего локального тега, у вас могут возникнуть проблемы.

Если вы все еще уверены, что хотите переместить тег (возможно, это один проект разработчика, или вы уверены, что никто не получил тег, или вы готовы общаться со всеми другими разработчиками и убедиться, что они обновляют свои локальные теги) вы можете сделать что-то вроде этого:

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

Другим разработчикам следует рекомендовать удалить свою локальную копию тега и получить новую:

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

Ответ 3

Вы также можете удалить тег, а затем воссоздать его, для этого не требуется переписывать историю.
(Нет push --force)

Удалить локальный и удаленный

git tag -d <tag_name>
git push origin :refs/tags/<tag_name>

Воссоздание

git tag <tag_name>
git push --tags