українська мова ▾ Topics ▾ Latest version ▾ git-tag last updated in 2.46.0

НАЗВА

git-tag - Створення, перегляд, видалення або перевірка об’єкта тегу, підписаного за допомогою GPG

СИНОПСИС

git tag [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] [-e]
	[(--trailer <token>[(=|:)<value>])…​]
	<tagname> [<commit> | <object>]
git tag -d <tagname>…​
git tag [-n[<num>]] -l [--contains <commit>] [--no-contains <commit>]
	[--points-at <object>] [--column[=<options>] | --no-column]
	[--create-reflog] [--sort=<key>] [--format=<format>]
	[--merged <commit>] [--no-merged <commit>] [<pattern>…​]
git tag -v [--format=<format>] <tagname>…​

ОПИС

Додати посилання на тег у refs/tags/, якщо не вказано -d/-l/-v для видалення, перегляду або перевірки тегів.

Якщо не вказано параметр -f, іменований тег ще не повинен існувати.

Якщо передано один із параметрів -a, -s або -u <ідентифікатор-ключа>, команда створює об’єкт tag та вимагає повідомлення тегу. Якщо не передано -m <повідомлення> або -F <файл>, запускається редактор, у який користувач може ввести повідомлення тегу.

Якщо вказано -m <повідомлення> або -F <файл> або --trailer <токен>[=<значення>], а -a, -s та -u <ідентифікатор-ключа> відсутні, мається на увазі -a.

В іншому випадку створюється посилання на тег, яке вказує безпосередньо на заданий об’єкт (тобто легкий тег).

Підписаний об’єкт тегу GnuPG буде створено, якщо використовується -s або -u <ідентифікатор-ключа>. Якщо -u <ідентифікатор-ключа> не використовується, для пошуку ключа GnuPG для підписання використовується ідентифікатор комітера поточного користувача. Змінна конфігурації gpg.program використовується для визначення власного бінарного файлу GnuPG.

Об’єкти тегів (створені за допомогою -a, -s або -u) називаються "анотованими" тегами; вони містять дату створення, ім’я та електронну адресу користувача тегу, повідомлення тегу та необов’язковий підпис GnuPG. Тоді як "легкий" тег - це просто ім’я об’єкта (зазвичай об’єкта коміту).

Анотовані теги призначені для випуску, тоді як легкі теги призначені для приватних або тимчасових міток об’єктів. З цієї причини деякі команди git для іменування об’єктів (наприклад, git describe) за замовчуванням ігноруватимуть легкі теги.

ОПЦІЇ

-a
--annotate

Створення непідписаного, анотованого об’єкта тегу

-s
--sign

Створіть тег, підписаний GPG, використовуючи ключ стандартної адреси електронної пошти. Стандартна поведінка підписання тегом GPG контролюється змінною конфігурації tag.gpgSign, якщо вона існує, або вимикається в іншому випадку. Див. git-config[1].

--no-sign

Перевизначити змінну конфігурації tag.gpgSign, яка встановлена для примусового підписання кожного тегу.

-u <key-id>
--local-user=<key-id>

Створіть тег, підписаний GPG, використовуючи заданий ключ.

-f
--force

Замінити існуючий тег заданою назвою (замість помилки)

-d
--delete

Видалити існуючі теги із заданими іменами.

-v
--verify

Перевірте GPG-підпис заданих імен тегів.

-n<num>

<num> визначає, скільки рядків з анотації, якщо такі є, друкуються при використанні -l. Має на увазі --list.

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

-l
--list

Перелік тегів. З необов’язковим параметром <шаблон>..., наприклад, git tag --list v-*', перелічує лише ті теги, що відповідають шаблону(ам).

Виконання команди "git tag" без аргументів також відображає всі теги. Шаблон є символом підстановки оболонки (тобто, зіставлення здійснюється за допомогою fnmatch(3)). Можна вказати кілька шаблонів; якщо будь-який з них збігається, тег відображається.

Цей параметр неявно надається, якщо надано будь-який інший параметр, подібний до списку, такий як --contains. Дивіться документацію для кожного з цих параметрів для отримання детальної інформації.

--sort=<key>

Сортування на основі заданого ключа. Додайте префікс - для сортування у порядку спадання значення. Ви можете використовувати опцію --sort=<ключ> кілька разів, і в цьому випадку останній ключ стає первинним ключем. Також підтримується "version:refname" або "v:refname" (імена тегів обробляються як версії). Порядок сортування "version:refname" також може залежати від змінної конфігурації "versionsort.suffix". Підтримувані ключі такі ж, як і в git for-each-ref. Порядок сортування за замовчуванням дорівнює значенню, налаштованому для змінної tag.sort, якщо вона існує, або лексикографічному порядку в іншому випадку. Див. git-config[1].

--color[=<when>]

Враховуйте будь-які кольори, зазначені в опції --format. Поле <when> має бути одним із значень always, never або auto (якщо <when> відсутнє, поводьтеся так, ніби було вказано always).

-i
--ignore-case

Теги сортування та фільтрації не враховують регістр.

--omit-empty

Не друкуйте новий рядок після відформатованих посилань, де формат розгортається до порожнього рядка.

--column[=<options>]
--no-column

Відображати список тегів у стовпцях. Синтаксис опцій дивіться у змінній конфігурації column.tag. --column та --no-column без опцій еквівалентні «always» та «never» відповідно.

Цей параметр застосовується лише під час перерахування тегів без рядків анотацій.

--contains [<commit>]

Перераховувати лише теги, що містять вказаний коміт (HEAD, якщо не вказано). Має на увазі --list.

--no-contains [<commit>]

Перераховувати лише теги, які не містять зазначеного коміту (HEAD, якщо не вказано). Має на увазі --list.

--merged [<commit>]

Перелічувати лише теги, коміти яких доступні з вказаного коміту (HEAD, якщо не вказано).

--no-merged [<commit>]

Перелічувати лише теги, коміти яких недоступні з вказаного коміту (HEAD, якщо не вказано).

--points-at <object>

Перераховувати лише теги заданого об’єкта (HEAD, якщо не вказано). Має на увазі --list.

-m <msg>
--message=<msg>

Використовувати надане повідомлення тегу (замість запиту). Якщо задано кілька опцій -m, їхні значення об’єднуються в окремі абзаци. Має на увазі -a, якщо не задано жодної з опцій -a, -s або -u <ідентифікатор-ключа>.

-F <file>
--file=<file>

Взяти повідомлення тегу з заданого файлу. Використати - для зчитування повідомлення зі стандартного вводу. Має на увазі -a, якщо не вказано жодного з -a, -s або -u <ідентифікатор-ключа>.

--trailer <token>[(=|:)<value>]

Вкажіть пару (<токен>, <значення>), яку слід застосувати як трейлер. (наприклад, git tag --trailer "Custom-Key: значення" додасть трейлер "Custom-Key" до повідомлення тегу). Змінні конфігурації trailer.* (git-interpret-trailers[1]) можна використовувати для визначення того, чи пропускається дублікат трейлера, де в рядку трейлерів з’явиться кожен трейлер та інших деталей. Трейлери можна витягти в git tag --list, використовуючи заповнювач --format="%(trailers)".

-e
--edit

Повідомлення, взяте з файлу з опцією -F та з командного рядка з опцією -m, зазвичай використовується як незмінне повідомлення тегу. Ця опція дозволяє вам додатково редагувати повідомлення, взяте з цих джерел.

--cleanup=<mode>

Цей параметр визначає спосіб очищення повідомлення тегу. Режим «<mode>» може мати один із варіантів: «verbatim», «whitespace» або «strip». Режим «strip» є режимом за замовчуванням. Режим «verbatim» взагалі не змінює повідомлення, «whitespace» видаляє лише початкові/заключні пробіли, а «strip» видаляє як пробіли, так і коментарі.

--create-reflog

Створіть журнал перепису для тегу. Щоб глобально ввімкнути журнали перепису для тегів, див. core.logAllRefUpdates у git-config[1]. Заперечувана форма --no-create-reflog лише перевизначає попередню форму --create-reflog, але наразі не скасовує налаштування core.logAllRefUpdates.

--format=<format>

Рядок, який інтерполює %(назваполя) з посилання на тег, що відображається, та об’єкта, на який воно вказує. Формат такий самий, як і у git-for-each-ref[1]. Якщо не вказано, за замовчуванням використовується %(refname:strip=2).

<tagname>

Назва тегу, який потрібно створити, видалити або описати. Нова назва тегу має пройти всі перевірки, визначені в git-check-ref-format[1]. Деякі з цих перевірок можуть обмежувати кількість символів, дозволених у назві тегу.

<commit>
<object>

Об’єкт, на який посилатиметься новий тег, зазвичай це коміт. За замовчуванням HEAD.

КОНФІГУРАЦІЯ

За замовчуванням, «git tag» у режимі sign-with-default (-s) використовуватиме вашу ідентифікацію комітера (формату Ваше ім'я <ваша@адреса_електронної_пошти>) для пошуку ключа. Якщо ви хочете використовувати інший ключ за замовчуванням, ви можете вказати його в конфігурації репозиторію наступним чином:

[user]
    signingKey = <gpg-key-id>

Параметр pager.tag враховується лише під час перерахування тегів, тобто коли використовується або мається на увазі -l. За замовчуванням використовується пейджер. Див. git-config[1].

ОБГОВОРЕННЯ

Про повторне тегування

Що робити, коли ви позначили неправильний коміт і хочете перепознати його?

Якщо ви ніколи нічого не виштовхували, просто перемініть тег. Використайте "-f", щоб замінити старий. І все готово.

Але якщо ви виклали дані (або інші могли просто читати ваш репозиторій безпосередньо), то інші вже бачили старий тег. У такому разі ви можете зробити одне з двох:

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

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

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

Якщо хтось отримав від вас тег випуску, ви не можете просто змінити його для нього, оновивши свій власний. Це велика проблема безпеки, оскільки люди ПОВИННІ довіряти своїм тегам. Якщо ви дійсно хочете зробити щось божевільне, вам потрібно просто зізнатися у своїй помилці та сказати людям, що ви помилилися. Ви можете зробити це, зробивши публічну заяву, в якій скажете:

Гаразд, я помилився і видав попередню версію з тегом X. Я
потім щось виправив і знову перепозначив *виправлене* дерево як X.

Якщо ви отримали неправильний тег і хочете новий, видаліть старий
Та отримайте новий, виконавши такі дії:

	git tag -d X
	git fetch origin tag X

щоб отримати мій оновлений тег.

Ви можете перевірити, який у вас тег, виконавши такі дії

	git rev-parse X

який має повернути 0123456789abcdef.. якщо у вас нова версія.

Вибачте за незручності.

Це здається трохи складним? Так і має бути. Просто «виправляти» це автоматично ніяк не можна. Люди повинні знати, що їхні теги могли бути змінені.

Увімкнено автоматичне підписання

Якщо ви слідуєте за чужим деревом, найімовірніше, ви використовуєте гілки віддаленого відстеження (наприклад, refs/remotes/origin/master). Зазвичай вам потрібні теги з іншого кінця.

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

Часто повідомлення типу «будь ласка, витягніть» у списку розсилки містять лише два фрагменти інформації: URL-адресу репозиторію та назву гілки; це розроблено для легкого копіювання та вставки в кінці командного рядка «git fetch»:

Лінусе, будь ласка, витягни з

	git://git..../proj.git master

щоб отримати наступні оновлення...

стає:

$ git pull git://git..../proj.git master

У такому випадку ви не хочете автоматично слідкувати за тегами іншої людини.

Одним із важливих аспектів Git є його розподілена природа, що значною мірою означає, що в системі немає внутрішнього «висхідного» чи «нижнього» рівня. На перший погляд, наведений вище приклад може здатися таким, що вказує на те, що простір імен тегів належить вищому ешелону людей, і що теги передаються лише вниз, але це не так. Це лише показує, що модель використання визначає, хто зацікавлений у чиїх тегах.

Одноразове вилучення (pull) – це ознака того, що історія комітів тепер перетинає межу між одним колом людей (наприклад, «люди, які в першу чергу зацікавлені в мережевій частині ядра»), які можуть мати власний набір тегів (наприклад, «це третій кандидат на реліз від мережі, який буде запропоновано для загального використання з релізом 2.6.21»), та іншим колом людей (наприклад, «люди, які інтегрують різні покращення підсистем»). Останні зазвичай не зацікавлені в детальних тегах, що використовуються внутрішньо в першій групі (саме це означає «внутрішній»). Ось чому в цьому випадку бажано не слідувати тегам автоматично.

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

Про теги зворотної дати

Якщо ви імпортували деякі зміни з іншої системи керування версіями (VCS) і хочете додати теги для основних релізів вашої роботи, корисно мати можливість вказати дату для вбудовування всередині об’єкта тегу; такі дані в об’єкті тегу впливають, наприклад, на порядок тегів в інтерфейсі gitweb.

Щоб встановити дату, яка використовуватиметься в майбутніх об’єктах тегів, встановіть змінну середовища GIT_COMMITTER_DATE (див. подальше обговорення можливих значень; найпоширеніша форма — «РРРР-ММ-ДД ГГ:ММ»).

Наприклад:

$ GIT_COMMITTER_DATE="2006-10-02 10:31" git tag -s v1.0.1

ФОРМАТИ ДАТИ

Змінні середовища GIT_AUTHOR_DATE та GIT_COMMITTER_DATE підтримують такі формати дати:

Внутрішній формат Git

Це <unix-timestamp> <time-zone-offset>, де <unix-timestamp> – це кількість секунд з епохи UNIX. <time-zone-offset> – це додатне або від’ємне зміщення відносно UTC. Наприклад, CET (що на 1 годину випереджає UTC) – це +0100.

RFC 2822

Стандартний формат дати, як описано в RFC 2822, наприклад, Чт, 07 квітня 2005 22:13:13 +0200.

ISO 8601

Час і дата, визначені стандартом ISO 8601, наприклад, 2005-04-07T22:13:13. Парсер також приймає пробіл замість символу T. Дробові частини секунди будуть ігноруватися, наприклад, 2005-04-07T22:13:13.019 буде оброблено як 2005-04-07T22:13:13.

Note
 Крім того, частина дати приймається в таких форматах: РРРР.ММ.ДД, ММ/ДД/РРРР та ДД.ММ.РРРР.

ФАЙЛИ

$GIT_DIR/TAG_EDITMSG

Цей файл містить повідомлення анотованого тегу, що створюється. Якщо git tag завершується через помилку перед створенням анотованого тегу, то повідомлення тегу, яке було надано користувачем у сеансі редактора, буде доступне в цьому файлі, але може бути перезаписано наступним викликом git tag.

НОТАТКИ

Під час поєднання кількох фільтрів --contains та --no-contains відображаються лише посилання, які містять принаймні один з комітів --contains та не містять жодного з комітів --no-contains.

Під час об’єднання кількох фільтрів --merged та --no-merged відображаються лише посилання, досяжні принаймні з одного з комітів --merged та з жодного з комітів --no-merged.

ДИВ. ТАКОЖ

git-check-ref-format[1]. git-config[1].

GIT

Частина набору git[1]