Переименование тегов git приводит к несогласованности

Ответ 1

Я столкнулся с тем же вопросом несколько минут назад. Ни один из уже представленных ответов не касался реальной проблемы, которая избавляется от сообщения warning: tag 'foo' is really 'bar' here и получает git describe, чтобы просто перечислить новое имя тега. Это было особенно важно в моем случае, поскольку моя система сборки использует git describe для записи в сборку, какие источники были использованы для создания сборки.

Репликация проблемы

Я могу воспроизвести проблему, выполнив следующие действия:

$ git tag foo --annotate -m"original message"
$ git tag bar foo
$ git tag -d foo
$ git describe 
warning: tag 'foo' is really 'bar' here
foo

(Флаг --annotate выше, поскольку -m подразумевает --annotate, но я включил его для выделения.) Я попытался воспроизвести проблему с помощью легкого тега, но не смог этого сделать, Поэтому, чтобы воспроизвести проблему, необходима аннотация.

Фиксация проблемы

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

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

Как только вы застряли с warning: tag 'foo' is really 'bar' here, вы должны сделать:

$ git tag bar bar -m"original message" --force
$ git describe 
bar

При необходимости адаптируйте, если сообщение необходимо изменить.

Чтобы удалить старый тег, если он уже был нажат:

$ git push origin :refs/tags/foo

Чтобы обновить новый тег, если он уже был нажат:

$ git push origin refs/tags/bar

Избегание проблемы

Чтобы избежать проблемы, в первую очередь вам нужно создать bar с помощью

$ git tag bar foo -m"original message"

Ответ 2

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

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

Если это так, в следующей статье приведены необходимые шаги: Как переименовать тег, уже перенесенный в удаленный git Repo.

Основные шаги:

git tag new_tag old_tag
git push --tags
git push origin :refs/tags/old_tag
git tag -d old_tag

Ответ 3

Нет, я не думаю, что это правильный рабочий процесс для тегов в git.

Основное правило git: Не связывайтесь с тем, что вы уже нажали.

Поскольку вы уже нажали тег 1.0, вы не хотите переименовывать его на локальном уровне 1.5, а затем пытаетесь его вытолкнуть. Оставьте тэг 1.0 для потомков, создайте новый тег 1.5 и нажмите его тоже. И действительно - для чего нужны теги. Таким образом, вы можете вернуться через 6 месяцев и заново создать свое программное обеспечение в версии 1.0.