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

НАЗВА

git-tag - Створення, перелік, видалення або перевірка тегів

СИНОПСИС

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.

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

Криптографічно підписаний об’єкт тегу буде створено, якщо використовується -s або -u <ідентифікатор-ключа>. Бекенд підпису (GPG, X.509, SSH тощо) контролюється змінною конфігурації gpg.format, за замовчуванням використовується OpenPGP. Коли -u <ідентифікатор-ключа> не використовується, для пошуку ключа для підпису використовується ідентифікатор комітера поточного користувача. Змінна конфігурації gpg.program використовується для визначення власного двійкового файлу підпису.

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

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

ОПЦІЇ

-a
--annotate

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

-s
--sign

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

--no-sign

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

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

Створіть криптографічно підписаний тег, використовуючи заданий ключ. Формат <key-id> та використаний сервер залежать від змінної конфігурації gpg.format. Див. git-config[1].

-f
--force

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

-d
--delete

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

-v
--verify

Перевірте криптографічний підпис заданих тегів.

-n<num>

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

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

-l
--list

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

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

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

--sort=<ключ>

Сортування на основі заданого ключа. Додайте префікс - для сортування у порядку спадання значення. Ви можете використовувати опцію --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[=<опція>]
--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>]

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

-m <msg>
--message=<повідомлення>

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

-F <файл>
--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> може мати один із варіантів: 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 = <key-id>

Бекенд підпису можна вибрати за допомогою змінної конфігурації gpg.format, яка за замовчуванням має значення openpgp. Див. список інших підтримуваних форматів у git-config[1].

Шлях до програми, що використовується для кожного сервера підписання, можна вказати за допомогою змінної конфігурації gpg.<format>.program. Для сервера openpgp gpg.program можна використовувати як синонім gpg.openpgp.program. Див. git-config[1] для отримання детальної інформації.

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.

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

Все, що знаходиться нижче цього рядка в цьому розділі, вибірково включено з документації git-config[1]. Вміст такий самий, як і там:

Warning

Missing uk/config/tag.adoc

See original version for this content.

НОТАТКИ

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

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

ДИВ. ТАКОЖ

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

GIT

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