Як перейменувати тег Git?

Сьогодні я переглянув журнали проекту та зрозумів, що деякий час тому я промацував ім'я тегу. Чи є спосіб перейменувати тег? Google не виявив нічого корисного.

Я розумію, що міг би перевірити теговану версію і зробити новий тег, я навіть це спробував. Але це, здається, створює об'єкт тегу, що не зовсім правильно. Для одного,

git tag -l

перераховує його поза порядком щодо всіх інших тегів. Я не маю уявлення, чи це важливо, але це змушує мене вважати, що новий об’єкт тегу - це не зовсім те, що я хочу. Я можу з цим жити, тому що мені дійсно важливо лише те, щоб ім'я тегу відповідало документації, але я вважаю за краще це зробити "правильно", припускаючи, що це правильно зробити.

Ось як я перейменую тег 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(це тому, що анотовані теги - це об'єкти, а легкі теги - немає більше інформації у цій відповіді ).

Первісне питання полягало в тому, як перейменувати тег, що легко: спочатку створити NEW як псевдонім OLD: git tag NEW OLDпотім видалити OLD : git tag -d OLD.

Цитата щодо "Git way" та (in) розумності не є базовою, оскільки йдеться про збереження імені тегу, але про те, щоб він посилався на інший стан сховища.

Окрім інших відповідей:

Перш за все , необхідно створити псевдонім з старого імені тега, вказуючи на оригінал фіксації:

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 Tag має для споживачів пакету!

Якщо він опублікований, ви не можете його видалити (не ризикуючи потрапити в таріум та пернати, тобто). "Git шлях" - це зробити:

Звичайна річ. Просто визнайте, що ви накрутили, і використовуйте іншу назву. Інші вже бачили одне ім’я тегів, і якщо ви збережете те саме ім’я, ви можете опинитися в ситуації, що двоє людей мають "версію X", але насправді вони мають різні "X". Тому просто називайте це "X.1" і будьте з ним.

Крім того,

Божевільна річ. Ви теж хочете назвати нову версію "X", навіть якщо інші вже бачили стару. Тому просто використовуйте git-tag -f знову, як ніби ви ще не опублікували старий.

Це так божевільно, бо:

Git не (і не повинен) міняти теги позаду користувачів назад. Тож, якщо хтось уже отримав старий тег, то виконуючи git-pull на вашому дереві, це не повинно просто змусити їх переписати старий.

Якщо хтось отримав від вас тег випуску, ви не можете просто змінити тег для них, оновивши власний. Це велика проблема безпеки, оскільки люди ОБОВ'ЯЗКОВО мати змогу довіряти своїм тегам-іменам. Якщо ви дійсно хочете зробити божевільну справу, вам потрібно просто розібратися з цим і сказати людям, що ви заплуталися.

Любність сторінок людини .

На цій вікі-сторінці є такий цікавий однокласник, який нагадує нам, що ми можемо натиснути кілька запитів :

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? ".

Як доповнення до інших відповідей, я додав псевдонім, щоб зробити це все за один крок, з більш звичним командою * 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

Дотримуйтесь 3-крокового підходу для однієї або декількох тегів.

Крок 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 буде готовий зі зміною назви тегу, ці зміни можуть бути повернуті до початкового коду для інших, щоб взяти їх.

Для пригод це можна зробити за допомогою однієї команди:

mv .git/refs/tags/OLD .git/refs/tags/NEW

Незалежно від проблем, які стосуються натискання тегів та перейменування тегів, які вже були надіслані, у випадку, якщо тег для перейменування є анотованим , спершу його можна скопіювати завдяки наступному однорядковому командному рядку:

git tag -a -m "`git cat-file -p old_tag | tail -n +6`" new_tag old_tag^{}

Потім просто потрібно видалити старий тег:

git tag -d old_tag

Я знайшов цей командний рядок завдяки наступним двом відповідям:

• https://stackoverflow.com/a/26132640/7009806 (другий коментар)
• https://stackoverflow.com/a/49286861/7009806

Редагувати:
зіткнувшись із проблемами автоматичної синхронізації налаштування тегів fetch.pruneTags=true(як описано в https://stackoverflow.com/a/49215190/7009806 ), я особисто пропоную спершу скопіювати новий тег на сервер, а потім видалити старий. Таким чином, новий тег не видаляється випадковим чином при видаленні старого тегу, а синхронізація тегів хотіла б видалити новий тег , якого ще немає на сервері . Так, наприклад, всі разом ми отримуємо:

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

Ви також можете перейменовувати віддалені теги, не перевіряючи їх, дублюючи старий тег / гілку до нового імені та видаляючи старий, в одній git pushкоманді.

Віддалений тег перейменування / Віддалений філія → тег конверсія: (Примітка: :refs/tags/)

git push <remote_name> <old_branch_or_tag>:refs/tags/<new_tag> :<old_branch_or_tag>

Віддалений філія перейменовувати / Remote тег → перетворення гілки: (Примітка: :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