У меня есть хранилище только с одной веткой (master). Я единственный участник моего репо.
Я недавно добавил tag, как локально, так и перенесенный на GitHub. После того, как я сделал последний необходимый коммит, но теперь я понимаю, что должен был сделать еще одно изменение/коммит.
Итак, что у меня есть:
commit 124
commit 125
commit 126 <-- tag v1.0
commit 127
и я хочу переместить тег v1.0 к следующему коммиту, то есть: 127, как локально, так и в GitHub.
Как я могу это сделать?
Вы когда-нибудь были в книжном клубе, где не все участники используют одно и то же издание "Книги недели"? Это кошмар, верно? Перемещение тега по сути поставит вас в ту же ситуацию.
Если вы думаете о своем хранилище как о книге, в которой рассказывается о прогрессе в вашем проекте, вы можете рассматривать тег как заголовок главы.
Переместить тег в другой коммит после публикации это все равно, что рассказать всем своим друзьям из книжного клуба
Вы знаете что, ребята? Издание книги, которое мы все использовали до сих пор, устарело, потому что я единолично постановил, что глава 8 теперь должна начаться не на странице 126, а на странице 128.
Нехорошо. Перемещение тега - это форма переписывания истории, и вы не должны переписывать историю, которой поделились. Это самый верный способ разозлить ваших сотрудников. Кроме того, ты пишешь
Я единственный участник моего репо [...]
На данный момент это может быть правдой, но если другие пользователи, кроме вас, имеют доступ к вашему репозиторию GitHub (например, если он общедоступный), некоторые из них, возможно, уже раздвоили или клонировали его (хотя есть способ выяснить это), и вы запускаете риск разозлить их, если переписать историю.
Если вы на 100% уверены, что хотите переместить этот тег в любом случае, Git позволит вам это сделать. Здесь вы можете использовать
git tag --force v1.0 <ID-of-commit-127>
и тогда вам придется принудительно нажать на этот тег, используя
git push --force --tags
Но опять же, подумайте дважды, прежде чем идти вперед...
Я чувствую необходимость пересмотреть мой ответ...
На протяжении многих лет некоторые люди в комментариях к моему запрету возражали не перемещать уже опубликованный тег. Конечно, этот совет скорее контекстуальный, чем универсальный; Я не сомневаюсь, что есть хорошие причины для перемещения опубликованного тега. Однако я твердо убежден в том, что, как правило, решение о перемещении опубликованного тега должно приниматься осознанно и с особой тщательностью.
Один недавний пример приходит на ум. В Go 1.11 добавлена экспериментальная поддержка модульной системы, которая в значительной степени опирается на теги Git для управления версиями. Перемещение тега в опубликованном модуле Go (скажем, на GitHub) будет иметь катастрофические последствия.
Таким образом, вы нарушите договор, заключенный между вами (автором модуля) и вашими пользователями (теми, кто зависит от вашего модуля), потому что вы отрицаете гарантии, которые система модулей Go намеревается предоставить:
Модули записывают точные требования к зависимостям и создают воспроизводимые сборки.
Это верный способ разозлить людей.
Этого примера может быть достаточно, чтобы убедить вас, что, по крайней мере, в некоторых случаях вы не должны бездумно перемещать опубликованные теги. Я считаю так.
Перемещение тегов, как правило, не рекомендуется, так как это может вызвать проблемы из-за высокой распространенности Git. Рассматривать:
v1.0 на abcd123v1.0 на abcd123v1.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
Вы также можете удалить тег, а затем воссоздать его, для этого не требуется переписывать историю.
(Нет push --force)
Удалить локальный и удаленный
git tag -d <tag_name>
git push origin :refs/tags/<tag_name>
Воссоздание
git tag <tag_name>
git push --tags