Создание тега в Git с помощью git tag

Введение

Теги в Git помогают зафиксировать важные точки в истории репозитория. Чаще всего ими помечают релизы, стабильные версии, крупные изменения. Представьте, что у вас есть длинная история коммитов, а через полгода вам нужно быстро вернуться к состоянию кода версии 1.2.0. Вместо того чтобы искать хэш коммита, вы просто обращаетесь к тегу.

Команда git tag как раз и используется для создания, просмотра, изменения и удаления тегов. В этой статье я покажу вам, как создавать разные типы тегов, как ими пользоваться в повседневной работе и как правильно работать с тегами в удаленных репозиториях.

Что такое тег в Git и зачем он нужен

Основная идея тегов

Тег в Git — это именованная ссылка на конкретный коммит. В отличие от веток, которые "двигаются" вперед при каждом новом коммите, тег всегда указывает на один и тот же коммит.

Это удобно, когда нужно:

• пометить релиз версии приложения, например v1.0.0
• зафиксировать состояние кода перед крупным рефакторингом
• отметить стабильную сборку, прошедшую все тесты
• использовать конкретную версию кода для деплоя или сборки пакета

Вы можете представить тег как наклейку с подписью, которую вы приклеиваете к конкретному коммиту.

Типы тегов в Git

Git поддерживает два основных типа тегов:

1. Легковесные теги (lightweight tag)

   • фактически это просто имя, указывающее на коммит
   • не содержат дополнительной информации
   • создаются быстро, чаще используются для локальных пометок

2. Аннотированные теги (annotated tag)

   • полноценный объект в базе Git
   • содержат имя автора тега, дату, сообщение, могут быть подписаны GPG
   • используются для релизов и долгоживущих меток, которые будут опубликованы

Давайте теперь по шагам разберемся, как создавать каждый из этих типов.

Просмотр существующих тегов

Перед тем как создавать новые теги, полезно уметь их просматривать. Это помогает понять, какие имена уже используются и какие версии есть в проекте.

Список всех тегов

Смотрите, вот базовая команда для просмотра всех тегов:

git tag
# Вывод - список всех тегов в алфавитном порядке

Если тегов много, такой вывод может быть неудобен. Ниже я покажу, как улучшить отображение.

Фильтрация тегов по шаблону

Часто теги именуют по одной схеме, например:

• v1.0.0
• v1.1.0
• v2.0.0-beta

Вы можете увидеть только нужную подгруппу тегов с помощью опции match:

git tag --list "v1.*"
# Показывает только теги, начинающиеся с v1.

Комментарии к примеру:

• v1.* — шаблон, где звездочка означает любую последовательность символов
• так можно, например, фильтровать только стабильные версии или только релизы конкретной ветки

Еще один пример:

git tag --list "v1.2.*"
# Показывает все патч-релизы серии v1.2.x

Показать тег и связанный с ним коммит

Иногда важно не просто увидеть имя тега, а посмотреть, к какому коммиту он привязан. Для этого удобно использовать команду show:

git show v1.0.0
# Показывает информацию о теге и коммите, на который он указывает

Git покажет:

• данные о теге (если он аннотированный)
• сообщение тега
• сам коммит, его автора, дату, сообщение и diff

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

Создание легковесного тега

Когда использовать легковесный тег

Легковесный тег — это просто имя, которое указывает на конкретный коммит. В нем:

• нет отдельного сообщения тега
• нет автора и даты тега (Git хранит только автора коммита)
• невозможно добавить подпись

Его удобно использовать:

• для временных, локальных пометок
• если вам нужно быстро "отметить" коммит, не планируя публиковать тег
• когда вы делаете черновые версии для себя

Базовый синтаксис

Давайте разберемся на примере:

git tag v1.0.0
# Создает легковесный тег v1.0.0 на текущем коммите (HEAD)

Комментарии к примеру:

• команда берет текущий коммит (HEAD) и привязывает к нему тег v1.0.0
• если вы хотите отметить не текущий, а другой коммит, можно указать его хэш

git tag v1.0.0 1a2b3c4d
# Создает тег v1.0.0 на коммите с хэшем 1a2b3c4d

Здесь важно:

• 1a2b3c4d — сокращенный хэш нужного коммита
• можно использовать полную или сокращенную форму, пока она однозначно определяет коммит

Проверка созданного тега

После создания тега лучше сразу убедиться, что он указывает на нужный коммит:

git show v1.0.0
# Показывает коммит, к которому привязан тег v1.0.0

Если вы видите ожидаемый коммит и diff, значит тег создан корректно.

Создание аннотированного тега

Зачем нужны аннотированные теги

Аннотированный тег — это более "официальный" способ помечать версии. Он хранится в Git как отдельный объект и содержит:

• имя автора тега
• дату создания тега
• сообщение тега
• опционально GPG подпись

Такой тег особенно полезен для:

• релизов, которые вы публикуете в общем репозитории
• версий, о которых вы хотите оставить больше информации
• интеграции с CI и релизными скриптами

Создание аннотированного тега с сообщением

Теперь вы увидите, как это выглядит в команде:

git tag -a v1.0.0 -m "Релиз версии 1.0.0"
# -a означает аннотированный тег
# -m задает сообщение для тега

Пояснения:

• флаг -a говорит Git создать аннотированный тег
• флаг -m позволяет передать сообщение прямо в командной строке
• сообщение стоит делать осмысленным, например указать основные изменения релиза

Вы также можете указать коммит:

git tag -a v1.0.0 -m "Релиз версии 1.0.0" 1a2b3c4d
# Помечаем тегом конкретный коммит по хэшу

Создание аннотированного тега с редактированием сообщения

Если вам нужно написать более длинное описание, можно не указывать -m, тогда откроется редактор по умолчанию:

git tag -a v1.0.0
# Откроется редактор, где вы можете написать подробное сообщение тега

В открывшемся редакторе вы обычно:

• пишете краткий заголовок на первой строке
• ниже (через пустую строку) даете более детальное описание релиза

Пример содержания сообщения тега:

• Релиз версии 1.0.0
• Добавлены основные модули авторизации
• Реализована базовая API обертка
• Исправлены критические ошибки в логике биллинга

Просмотр аннотированного тега

После создания аннотированного тега полезно посмотреть, что именно было сохранено:

git show v1.0.0
# Показывает:
# - автора и дату тега
# - сообщение тега
# - коммит, на который он указывает
# - diff этого коммита

Обратите внимание, как Git выводит сначала информацию о теге (tag), а уже потом информацию о коммите (commit). Это отличает аннотированный тег от легковесного.

Сравнение легковесных и аннотированных тегов на практике

Чтобы вам было проще понять разницу, давайте сравним их поведение на примере.

Предположим, вы создали два тега:

git tag v0.9.0        # легковесный
git tag -a v1.0.0 -m "Релиз 1.0.0"   # аннотированный

Теперь смотрим:

git show v0.9.0
# Вы увидите только информацию о коммите
# Поскольку тег легковесный, у него нет собственного автора и сообщения

git show v1.0.0
# Сначала будет информация о теге (автор тега, дата, сообщение)
# Затем информация о коммите и diff

Рекомендация на практике:

• для релизов и версий, которые живут долго и уходят в общий репозиторий, лучше всегда использовать аннотированные теги
• легковесные теги можно использовать для временных, локальных целей

Создание тегов для уже существующих релизов

Иногда бывает, что релиз уже состоялся, коммит в продакшене, а тег вы забыли поставить. Такое легко исправить.

Поиск нужного коммита

Сначала нужно найти хэш коммита, который соответствует релизу. Чаще всего это делается через журнал:

git log --oneline
# Показывает список коммитов в сокращенном виде:
# 1a2b3c4d Фикс бага в модуле оплаты
# 9f8e7d6c Релиз версии 1.0.0
# ...

Предположим, вы нашли коммит с сообщением "Релиз версии 1.0.0" и хэшем 9f8e7d6c.

Назначение тега на старый коммит

Теперь можно создать тег, указывая этот хэш:

git tag -a v1.0.0 -m "Релиз 1.0.0" 9f8e7d6c
# Обратите внимание:
# - тег создается сейчас, хотя сам коммит старый
# - это нормальный и частый сценарий

Потом вы можете проверить:

git show v1.0.0
# Убедитесь, что тег указывает именно на нужный релизный коммит

Переименование и перемещение тегов

Иногда вы ошиблись в имени тега или привязали его не к тому коммиту. Здесь важно действовать аккуратно, особенно если тег уже отправлен в удаленный репозиторий.

Переименование локального тега

Прямой команды git tag rename нет, но можно сделать так:

1. Создать новый тег на том же коммите
2. Удалить старый тег

Предположим, у вас есть тег v1.00.0, а нужно v1.0.0.

git tag v1.0.0 v1.00.0
# Создаем новый тег v1.0.0, указывающий на тот же коммит, что и v1.00.0

git tag -d v1.00.0
# Удаляем старый тег

Комментарии:

• в первой команде второй аргумент v1.00.0 трактуется как имя коммита или тега
• Git найдет коммит, на который указывает тег v1.00.0, и создаст новый тег на него

Перенос тега на другой коммит

Если вы хотите, чтобы тег указывал на другой коммит (например, был поставлен слишком рано), можно:

git tag -d v1.0.0
# Сначала удалить старый тег локально

git tag -a v1.0.0 -m "Релиз 1.0.0" новый_хэш
# Создать тег с тем же именем на нужном коммите

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

Подпись тегов GPG

В некоторых командах или в проектах с высокими требованиями к безопасности используют подпись тегов GPG. Это помогает подтвердить, что тег действительно создан конкретным человеком с конкретным ключом.

Создание подписанного тега

Если у вас настроен GPG ключ в Git, вы можете создать подписанный тег:

git tag -s v1.0.0 -m "Релиз 1.0.0"
# -s означает создание подписанного тега (signed tag)

При этом:

• Git попросит пароль от GPG ключа
• будет создан аннотированный тег с GPG подписью

Потом его можно проверить:

git tag -v v1.0.0
# -v проверяет подпись тега

Если подпись корректна, вы увидите сообщение о валидной подписи и информацию о ключе, которым она сделана.

Когда стоит использовать подписанные теги

Подписанные теги стоит применять, когда:

• важна гарантия, что релиз помечен конкретным человеком
• вы публикуете код в открытом доступе и хотите предотвратить подмену тегов
• в компании или сообществе есть политика обязательной подписи релизов

Работа с удаленными тегами

Создать тег локально — это только половина дела. Если вы хотите, чтобы им могли пользоваться другие разработчики или CI системы, нужно отправить тег в удаленный репозиторий.

Отправка одного тега на удаленный репозиторий

Чтобы отправить конкретный тег, используйте:

git push origin v1.0.0
# Отправляет тег v1.0.0 на удаленный репозиторий origin

После этого:

• тег появится у всех, кто работает с этим репозиторием
• его можно будет использовать в CI, сборках, деплое

Отправка всех локальных тегов

Если тегов много и вы хотите отправить их все разом, можно сделать так:

git push origin --tags
# Отправляет все локальные теги на удаленный репозиторий

Обратите внимание:

• эта команда отправит все теги, которые есть локально, но которых нет на сервере
• будьте аккуратны, если у вас есть временные или тестовые теги, которые вы не хотели бы публиковать

Получение тегов от других разработчиков

Если в удаленном репозитории уже есть теги, но локально вы их еще не видите, можно их подтянуть:

git fetch --tags
# Загружает все теги из удаленного репозитория, не трогая ваши ветки

Вы также можете использовать обычный git fetch, он тоже подтягивает теги, но с некоторыми нюансами. Команда git fetch --tags более явно говорит Git, что нужны именно теги.

Удаление тегов

Иногда теги создаются ошибочно или становятся неактуальными. В таких случаях их можно удалить локально и на удаленном сервере.

Удаление локального тега

Удалить тег в локальном репозитории просто:

git tag -d v1.0.0
# Удаляет локальный тег v1.0.0

Пояснение:

• коммит, на который указывал тег, остается в истории
• удаляется только ссылка с именем v1.0.0

Удаление тега на удаленном репозитории

Если тег уже был отправлен на сервер, удаление локально недостаточно. Нужно удалить его и на удаленной стороне.

Смотрите, я покажу вам, как это делается:

git push origin :refs/tags/v1.0.0
# Пуш "пустой" ссылки вместо тега удаляет тег v1.0.0 на origin

Более короткая форма, поддерживаемая новыми версиями Git:

git push origin --delete v1.0.0
# Удаляет тег v1.0.0 на удаленном репозитории origin

После этого:

• тег исчезнет с сервера
• другие разработчики смогут удалить его локально или при следующем fetch

Важно: если тег уже использовался кем-то для сборок или релизов, стоит заранее сообщить команде об удалении или переопределении тега.

Использование тегов в повседневной работе

Проверка кода на определенной версии

Частый сценарий: нужно воспроизвести баг или посмотреть состояние кода на конкретной версии. Здесь теги очень удобны.

Например, чтобы переключиться на версию v1.0.0:

git checkout v1.0.0
# Переключает рабочее дерево в состояние, соответствующее тегу
# HEAD при этом указывает на "detached HEAD" (не на ветку)

Комментарии:

• вы переходите в состояние detached HEAD, то есть не на ветку, а на конкретный коммит
• любые новые коммиты в этом состоянии не будут принадлежать ветке, пока вы сами не создадите ее

Если вы хотите не только посмотреть, но и доработать код от этого тега, лучше сразу создать ветку:

git checkout -b hotfix-1.0.1 v1.0.0
# Создает ветку hotfix-1.0.1 от тега v1.0.0 и сразу переключается на нее

Теперь вы можете:

• вносить изменения
• коммитить
• позже создать новый тег, например v1.0.1, на нужном коммите этой ветки

Сравнение версий по тегам

Иногда нужно понять, что изменилось между двумя релизами. Для этого можно сравнить два тега:

git diff v1.0.0 v1.1.0
# Показывает изменения между версиями 1.0.0 и 1.1.0

Вы также можете посмотреть список коммитов между тегами:

git log v1.0.0..v1.1.0
# Показывает коммиты, которые есть в 1.1.0, но нет в 1.0.0

Обратите внимание, как этот фрагмент команд помогает анализировать, какие изменения были внесены между релизами.

Использование тегов в CI и деплое

Многие системы CI и инструменты деплоя используют теги как триггеры для сборки релизных версий. Сценарий может выглядеть так:

1. Разработчик создает аннотированный тег v1.2.0
2. Отправляет его на сервер командой git push origin v1.2.0
3. CI видит новый тег и запускает релизный pipeline
4. На основе тегированного коммита собирается релизный артефакт

Поэтому важно:

• придерживаться внятной схемы именования тегов (например SemVer vМажор.Минор.Патч)
• использовать именно аннотированные теги для релизов
• не переиспользовать имена тегов и не "переносить" релизные теги на другие коммиты без крайней необходимости

Рекомендации по именованию и практике работы с тегами

Именование тегов для релизов

Чаще всего для версий используют схему SemVer:

• v1.0.0
• v1.2.3
• v2.0.0-rc1

Рекомендуется:

• всегда начинать имя версии с буквы v, чтобы отличать теги версий от других тегов
• использовать три числа Мажор.Минор.Патч
• для предварительных версий добавлять суффиксы, например v2.0.0-beta1

Примеры:

• v1.0.0 — первый стабильный релиз
• v1.1.0 — добавлены новые фичи, обратная совместимость сохранена
• v1.1.1 — исправлены ошибки без добавления новых фич
• v2.0.0 — несовместимые изменения

Отдельные теги для технических точек

Кроме релизов можно создавать теги для:

• важных миграций базы данных, например db-migration-2024-01
• контрольных точек по спринтам, например sprint-15-demo
• внутренних меток для анализа производительности

Но такие теги:

• лучше не отправлять в общий репозиторий, если они несут чисто локальный смысл
• либо четко договориться в команде, как и для чего они используются

Типичные ошибки при работе с тегами

Давайте посмотрим, какие проблемы часто возникают:

1. Создание легковесных тегов для публичных релизов

   • тогда теряется информация об авторе и описании релиза
   • лучше использовать аннотированные теги

2. Переиспользование имени тега для другого коммита без явного согласования

   • это может ломать сборки, которые ожидали другое содержимое по этому тегу
   • такие изменения требуют обсуждения в команде

3. Забывание о том, что тег не обновляется автоматически

   • тег остается на том же коммите, даже если вы продолжаете работу
   • если хотите пометить новую версию, создайте новый тег, а не пытайтесь "сдвинуть" старый

4. Публикация лишних временных тегов

   • git push origin --tags отправляет все локальные теги
   • если у вас есть временные, лучше явно указывать нужные теги в push

Заключение

Команда git tag — это простой, но очень мощный инструмент маркировки истории в Git. С ее помощью вы можете:

• помечать релизы и важные версии кода
• быстро возвращаться к нужным состояниям проекта
• интегрировать процесс релиза с CI и инструментами деплоя

Главные практические моменты, которые стоит запомнить:

• используйте аннотированные теги для релизов и публичных версий
• давайте тегам осмысленные имена, лучше по схеме SemVer
• аккуратно работайте с удаленными тегами, особенно при их переопределении или удалении
• не забывайте отправлять нужные теги в удаленный репозиторий и подтягивать теги от коллег

Опираясь на эти принципы и примеры команд, которые мы разобрали, вы сможете настроить понятный и управляемый процесс релизов в своем проекте.

Частозадаваемые технические вопросы по теме статьи и ответы на них

Как сделать так, чтобы при git clone сразу подтягивались все теги

По умолчанию git clone уже скачивает теги, связанные с загружаемыми ветками. Но если вы хотите убедиться, что у вас точно есть все теги, сразу после клонирования выполните:

git fetch --tags
# Явно загружает все теги из удаленного репозитория

Как увидеть, какие теги указывают на один и тот же коммит

Иногда один и тот же коммит помечают несколькими тегами. Чтобы это увидеть, выполните:

git show-ref --tags
# Показывает список тегов и соответствующие им хэши коммитов
# Можно визуально отследить теги с одинаковыми хэшами

Или посмотреть теги на текущем коммите:

git tag --points-at HEAD
# Показывает все теги, указывающие на текущий коммит

Как узнать, какие теги ссылаются на коммит по его хэшу

Если у вас есть хэш коммита, можно вывести теги, которые на него указывают:

git tag --points-at 1a2b3c4d
# Показывает теги, привязанные к коммиту с указанным хэшем

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

Как запретить перезапись уже существующих тегов на сервере

В корпоративных репозиториях часто хотят защитить теги от перезаписи. Для этого администратор Git сервера (например GitLab или GitHub Enterprise) настраивает политику защиты тегов. На стороне Git есть опция receive.denyDeletes и receive.denyNonFastForwards в настройках сервера, которые можно включить:

git config --system receive.denyDeletes true
git config --system receive.denyNonFastForwards true
# Эти настройки запрещают удалять и перезаписывать теги и ветки пушем

Настройка делается администратором на сервере, а не в локальном репозитории.

Как вывести теги в порядке создания, а не по алфавиту

Стандартная команда git tag сортирует теги по имени. Чтобы увидеть теги в порядке создания коммитов, на которые они указывают, можно сделать так:

git tag --sort=creatordate
# Сортирует теги по дате создания объекта тега (для аннотированных тегов)

Или по дате коммита:

git tag --sort=taggerdate
# Сортирует по дате автора тега, если информация есть