Как вы переименовываете тег Git?
Сегодня я просматривал журналы для проекта и понял, что я давно нащупал имя тега некоторое время назад. Есть ли способ переименовать тег? Google не нашел ничего полезного.
Я понимаю, что могу проверить тегированную версию и создать новый тег, я даже пробовал это. Но это похоже на создание объекта тега, который не совсем прав. Для одного,
git tag -l
перечисляет его не по порядку относительно всех других тегов. Я не знаю, насколько это значимо, но это заставляет меня думать, что новый объект тега не совсем то, что я хочу. Я могу жить с этим, потому что мне действительно все равно, что имя тега соответствует документации, но я предпочел бы сделать это "правильно", предполагая, что есть правильный способ сделать это.
Ответы
Ответ 1
Вот как я переименую тег old
в new
:
git tag new old
git tag -d old
git push origin :refs/tags/old
git push --tags
Двоеточие в команде push удаляет тег из удаленного хранилища. Если вы этого не сделаете, Git создаст старый тег на вашем компьютере, когда вы извлечете его.
Наконец, убедитесь, что другие пользователи удаляют удаленный тег. Пожалуйста, скажите им (коллегам) выполнить следующую команду:
git pull --prune --tags
Обратите внимание: если вы изменяете аннотированный тег, вам нужно убедиться, что имя нового тега ссылается на базовый коммит, а не на старый объект аннотированного тега, который вы собираетесь удалить. Поэтому используйте git tag -a new old^{}
вместо git tag new old
(это связано с тем, что аннотированные теги являются объектами, в то время как легкие теги - нет, дополнительная информация в этом ответе).
Ответ 2
Первоначальный вопрос заключался в том, как переименовать тег, что легко: сначала создайте NEW как псевдоним OLD: git tag NEW OLD
, затем удалите OLD: git tag -d OLD
.
Цитата, касающаяся "пути Git" и (в) здравомыслии, не соответствует действительности, потому что она говорит о сохранении имени тега, но заставляет его ссылаться на другое состояние хранилища.
Ответ 3
В дополнение к другим ответам:
Сначала необходимо создать псевдоним старого имени тега, указывающий на исходный коммит:
git tag new old^{}
Затем вам нужно удалить старый локально:
git tag -d old
Затем удалите тег из удаленного местоположения:
# Check your remote sources:
git remote -v
# The argument (3rd) is your remote location,
# the one you can see with 'git remote'. In this example: 'origin'
git push origin :refs/tags/old
Наконец, вам нужно добавить новый тег в удаленное местоположение. Пока вы этого не сделаете, новые теги не будут добавлены:
git push origin --tags
Повторяйте это для каждого удаленного местоположения.
Имейте в виду, что подразумевает, что изменение тега Git имеет для потребителей пакета!
Ответ 4
Если он опубликован, вы не можете удалить его (не рискуя быть заархивированным и обработанным). "Git way" - это сделать:
Нормальная вещь. Просто признай, что ты облажался, и используй другое имя. Другие уже видели одно имя тега, и если вы сохраняете одно и то же имя, вы можете оказаться в ситуации, когда два человека имеют "версию X", но на самом деле они имеют разные "X". Так что просто назовите его "X.1" и покончите с этим.
В качестве альтернативы,
Безумная вещь. Вы действительно хотите также назвать новую версию "Х", хотя другие уже видели старую. Так что просто используйте git-tag -f снова, как будто вы еще не опубликовали старый.
Это так безумно, потому что:
Git не изменяет (и не должен) изменять теги пользователей. Так что, если кто-то уже получил старый тег, выполнение мерзавца на вашем дереве не должно просто заставить его перезаписать старый.
Если кто-то получил от вас тег выпуска, вы не можете просто изменить тег для него, обновив свой собственный. Это большая проблема безопасности, поскольку люди ДОЛЖНЫ иметь возможность доверять своим именам тегов. Если вы действительно хотите сделать безумную вещь, вам нужно просто признать это и сказать людям, что вы все испортили.
Все предоставлено справочными страницами.
Ответ 5
На этой вики-странице есть интересный однострочный текст, который напоминает нам о том, что мы можем нажать несколько ссылок:
git push origin <refs/tags/old-tag>:<refs/tags/new-tag> :<refs/tags/old-tag> && git tag -d <old-tag>
и попросить других клонеров сделать git pull --prune --tags
Так что идея состоит в том, чтобы нажать:
<new-tag>
для каждого коммита, на который ссылается <old-tag
>: <refs/tags/old-tag>:<refs/tags/new-tag>
,
- удаление
<old-tag>
: :<refs/tags/old-tag>
См. в качестве примера "Изменить соглашение об именовании тегов в репозитории git?".
Ответ 6
Как дополнение к другим ответам, я добавил псевдоним, чтобы сделать все это за один шаг, с более знакомой командой * nix move. Аргумент 1 - это имя старого тега, аргумент 2 - новое имя тега.
[alias]
renameTag = "!sh -c 'set -e;git tag $2 $1; git tag -d $1;git push origin :refs/tags/$1;git push --tags' -"
Использование:
git renametag old new
Ответ 7
Выполните трехэтапный подход для одного или нескольких тегов.
Шаг 1. Определите идентификатор коммита/объекта для коммита, на который указывает текущий тег
command: git rev-parse <tag name>
example: git rev-parse v0.1.0-Demo
example output: db57b63b77a6bae3e725cbb9025d65fa1eabcde
Шаг 2. Удалить тег из хранилища
command: git tag -d <tag name>
example: git tag -d v0.1.0-Demo
example output: Deleted tag 'v0.1.0-Demo' (was abcde)
Шаг 3. Создайте новый тег, указывающий на тот же идентификатор фиксации, на который указывал старый тег
.
command: git tag -a <tag name> -m "appropriate message" <commit id>
example: git tag -a v0.1.0-full -m "renamed from v0.1.0-Demo" db57b63b77a6bae3e725cbb9025d65fa1eabcde
example output: Nothing or basically <No error>
Когда локальный git готов к изменению имени тега, эти изменения могут быть перенесены обратно в источник, чтобы другие могли их принять.
Ответ 8
Для приключений это можно сделать по одной команде:
mv .git/refs/tags/OLD .git/refs/tags/NEW
Ответ 9
Независимо от проблем, связанных с отправкой тегов и переименованием тегов, которые уже были переданы, в случае, если тег для переименования является аннотированным, вы можете сначала скопировать его благодаря следующей однострочной командной строке:
git tag -a -m "'git cat-file -p old_tag | tail -n +6'" new_tag old_tag^{}
Затем вам просто нужно удалить старый тег:
git tag -d old_tag
Я нашел эту командную строку благодаря следующим двум ответам:
Изменить:
Столкнувшись с проблемами при использовании автоматической синхронизации настройки тегов fetch.pruneTags=true
(как описано в fooobar.com/questions/180524/...), я лично предлагаю сначала скопировать новый тег на сервер и , а затем удалить старый один. Таким образом, новый тег не удаляется случайным образом при удалении старого тега, и синхронизация тегов хотела бы удалить новый тег, которого еще нет на сервере. Так, например, все вместе мы получаем:
git tag -a -m "'git cat-file -p old_tag | tail -n +6'" new_tag old_tag^{}
git push --tags
git tag -d old_tag
git push origin :refs/tags/old_tag
Ответ 10
Легкая часть - это переименование локальных тегов. Более жесткая часть - отдаленные.
Идея этого трюка состоит в том, чтобы дублировать старый тег/ветвь на новый и удалять старый, без проверки.
Удаленное переименование тегов/Удаленная ветка → преобразование тегов: (Примечание: :refs/tags/
)
git push <remote_name> <old_branch_or_tag>:refs/tags/<new_tag> :<old_branch_or_tag>
Удаленное переименование ветки/Удаленный тег → преобразование ветки: (Примечание: :refs/heads/
)
git push <remote_name> <old_branch_or_tag>:refs/heads/<new_branch> :<old_branch_or_tag>
Вывод, переименовывающий удаленный тег:
D:\git.repo>git push gitlab App%2012.1%20v12.1.0.23:refs/tags/App_12.1_v12.1.0.23 :App%2012.1%20v12.1.0.23
Total 0 (delta 0), reused 0 (delta 0)
To https://gitlab.server/project/repository.git
- [deleted] App%2012.1%20v12.1.0.23
* [new tag] App%2012.1%20v12.1.0.23 -> App_12.1_v12.1.0.23