Просмотр тегов в Git - команды и практические примеры

Введение

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

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

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

Я буду опираться на реальные сценарии использования, чтобы вам было проще перенести эти примеры в свою повседневную работу.

Базовые способы просмотра тегов

Вывод всех тегов

Самая простая команда для просмотра тегов:

git tag

По умолчанию она выведет список всех тегов в репозитории, отсортированный по алфавиту.

Например, вы можете увидеть:

$ git tag
v1.0.0
v1.1.0
v1.2.0
v2.0.0

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

git tag          # Показывает все локальные теги в алфавитном порядке

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

Просмотр тегов с выводом в одну строку

Иногда вам хочется видеть теги построчно, но в более компактном виде, например, когда тегов очень много. Для этого все равно используется git tag, просто вы можете подключать другие инструменты, такие как sort или форматированный вывод через git for-each-ref. Пока оставим это в базовом виде, а к форматированию мы еще вернемся.

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

Чем крупнее проект, тем больше в нем тегов. Перебирать весь список глазами становится неудобно. Поэтому Git позволяет отфильтровать результат по имени.

Фильтр по шаблону через опцию -l или --list

Вы можете передать git tag шаблон, чтобы показать только часть тегов:

git tag -l "v1.*"

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

git tag -l "v1.*"   # Показывает только теги, которые начинаются с "v1."
                    # Например: v1.0.0 v1.1.0 v1.2.3

Несколько примеров, чтобы вы увидели, как это работает:

git tag -l "v2.*"       # Все теги версии 2.x
git tag -l "*beta*"     # Все теги с подстрокой "beta"
git tag -l "release-*"` # Все теги, начинающиеся с "release-"

По сути в шаблоне используются shell-подобные маски:

• * — любая последовательность символов;
• ? — любой один символ;
• [abc] — один из символов a, b или c;
• [0-9] — любая цифра.

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

git tag -l "v1.?.0"

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

git tag -l "v1.?.0"  # Найдет v1.0.0 v1.1.0 v1.2.0, но не v1.10.0
                     # ? соответствует ровно одному символу

Вы также можете использовать git tag без -l, просто передав шаблон:

git tag "v1.*"

Это будет работать так же, как и git tag -l "v1.*". Опция -l явно подчеркивает, что вы хотите список тегов, поэтому я буду использовать ее для наглядности.

Показать сразу несколько групп тегов

Вы можете передать несколько шаблонов сразу:

git tag -l "v1.*" "v2.*"

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

git tag -l "v1.*" "v2.*"  # Показать все теги версий 1.x и 2.x

Git выведет все теги, подходящие хотя бы под один шаблон.

Просмотр деталей тегов

Простой список имен тегов часто недостаточен. Хотите понять, на какой коммит указывает тег, кто его создал, что написано в сообщении? Здесь как раз вступают в игру аннотированные теги и подробный просмотр.

Разница между легковесными и аннотированными тегами

Прежде чем смотреть детали, стоит четко разделить два вида тегов:

• Легковесный тег — просто имя, указывающее на конкретный коммит. Дополнительной информации (автор, дата, сообщение) он не содержит.
• Аннотированный тег — полноценный объект в базе Git. У него есть автор, дата создания, сообщение (часто с описанием релиза или важными изменениями).

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

git tag v1.0.0

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

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

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

git tag -a v1.0.0 -m "Релиз версии 1.0.0"

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

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

Теперь давайте посмотрим, как просматривать эти теги.

Просмотр аннотированного тега через git show

Чтобы увидеть подробную информацию по тегу, используйте команду git show:

git show v1.0.0

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

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

Пример вывода для аннотированного тега:

$ git show v1.0.0
tag v1.0.0
Tagger: Ivan Petrov <ivan@example.com>
Date:   Mon Oct 21 10:00:00 2024 +0300

Релиз версии 1.0.0

commit 3a1b5c51a962b8a...
Author: Ivan Petrov <ivan@example.com>
Date:   Mon Oct 21 09:30:00 2024 +0300

    Добавлена основная функциональность

diff --git a/main.go b/main.go
...

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

• вначале Git показывает объект тега (Tagger, Date, сообщение тега);
• затем идет сам коммит, на который указывает тег.

Если тег легковесный, то объекта тега нет, и git show сразу покажет коммит:

$ git show v1.0.0
commit 3a1b5c51a962b8a...
Author: Ivan Petrov <ivan@example.com>
Date:   Mon Oct 21 09:30:00 2024 +0300

    Добавлена основная функциональность

diff --git a/main.go b/main.go
...

Просмотр только сообщения тега без diff

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

Способ 1 — ограничить лог:

git show --no-patch v1.0.0

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

git show --no-patch v1.0.0
# Показывает:
# - объект тега
# - заголовок коммита
# Но не показывает diff по файлам

Способ 2 — использовать git tag с опцией --format и git cat-file, но для большинства задач git show --no-patch достаточно.

Просмотр только объекта тега без коммита

Если вы хотите увидеть только информацию об объекте тега (кто создал, когда, какое сообщение), можно воспользоваться git cat-file, но есть более понятный путь — комбинировать git for-each-ref. Чуть позже я покажу это в разделе о форматировании вывода.

Связка тегов и коммитов

Очень часто вам нужно связать конкретный коммит и теги:

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

Нахождение тегов, указывающих на конкретный коммит

Для этого используется git tag с опцией --points-at:

git tag --points-at <commit>

Например:

git tag --points-at HEAD

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

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

Если вы хотите проверить конкретный хеш:

git tag --points-at 3a1b5c51

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

git tag --points-at 3a1b5c51
# Найдет все теги, которые указывают на указанный коммит
# Удобно для проверки, "помечен" ли коммит релизом

Узнать тег, ближайший к коммиту (git describe)

Еще одна полезная команда — git describe. Она не просто показывает теги, а пытается найти ближайший тег в истории относительно коммита и сформировать человекочитаемое имя.

Пример:

git describe --tags

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

git describe --tags
# Ищет ближайший тег в истории от HEAD
# Возвращает строку вида v1.2.0-5-g3a1b5c5
# где:
#  v1.2.0 — ближайший тег
#  5      — количество коммитов сверху этого тега
#  g3a1b5c5 — сокращенный хеш текущего коммита

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

Если вы хотите описать конкретный коммит:

git describe --tags 3a1b5c51

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

git describe --tags 3a1b5c51
# Определяет ближайший тег для указанного коммита

Имейте в виду, что git describe учитывает только аннотированные теги по умолчанию. Если вы хотите включить легковесные теги, используйте ключ --all, но тогда в описании могут появляться и имена веток.

Просмотр тегов в удаленных репозиториях

Многие путаются, когда речь идет о тегах на удаленном сервере (например, GitHub, GitLab) и тегами локально. Давайте разберемся, как их просматривать и синхронизировать.

Получить теги с удаленного репозитория

Когда вы делаете обычный git fetch или git pull, теги не всегда подтягиваются автоматически (зависит от настроек), а главное — это поведение иногда неочевидно. Чтобы явно получить все теги, используйте:

git fetch --tags

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

git fetch --tags
# Забирает все теги с удаленного репозитория
# и создает соответствующие теги локально

После этого команда git tag покажет и те теги, которые пришли с сервера.

Просмотр тегов, хранящихся в пространстве refs/tags

Теги — это ссылки в пространстве refs/tags. Вы можете посмотреть их через git show-ref:

git show-ref --tags

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

git show-ref --tags
# Показывает соответствие "хеш коммита — имя тега"
# Пример строки:
# 3a1b5c51a962b8a... refs/tags/v1.0.0

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

Список всех тегов, существующих на удаленном

Когда вы работаете с удаленным репозиторием, сами теги хранятся просто как обычные теги. Разницы "локальный/удаленный тег" нет — есть локальный тег, который вы синхронизируете через push и fetch.

Чтобы увидеть теги на удаленном, есть два типичных пути:

1. Получить их к себе:

   git fetch --tags
   git tag -l
   

2. Или посмотреть через интерфейс Git-сервера (например, раздел "Releases" на GitHub).

Сама команда git ls-remote тоже умеет показывать теги без загрузки:

git ls-remote --tags origin

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

git ls-remote --tags origin
# Показывает какие теги есть на удаленном origin
# Каждая строка - хеш и имя ссылки refs/tags/<tagname>

Расширенный форматированный вывод тегов

Если вы хотите увидеть не только имя тега, но и к какому коммиту он относится, когда был создан и какое сообщение у коммита, удобнее использовать git for-each-ref.

Теги в Git хранятся в refs/tags, и вы можете обойти их как обычные ссылки.

Простой форматированный список тегов

Давайте сформируем удобный список "имя тега — дата коммита — сообщение коммита":

git for-each-ref refs/tags --sort=creatordate \
  --format="%(refname:short)  %(creatordate:short)  %(subject)"

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

git for-each-ref refs/tags --sort=creatordate \
  --format="%(refname:short)  %(creatordate:short)  %(subject)"
# refname:short        — короткое имя тега (без refs/tags/)
# creatordate:short    — дата создания объекта (для аннотированных тегов - дата тега)
# subject              — тема (первая строка сообщения) коммита или тега

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

Сортировка тегов

Параметр --sort позволяет менять порядок:

• --sort=creatordate — по дате создания тега;
• --sort=-creatordate — по дате создания в обратном порядке (новые вверху);
• --sort=taggerdate — по дате тега (для аннотированных тегов);
• --sort=refname — по имени тега (по умолчанию).

Пример, показывающий самые новые теги сверху:

git for-each-ref refs/tags --sort=-creatordate \
  --format="%(refname:short)  %(creatordate:short)  %(subject)"

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

git for-each-ref refs/tags --sort=-creatordate \
  --format="%(refname:short)  %(creatordate:short)  %(subject)"
# Отсортировано по дате создания - от новых к старым

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

Иногда вам нужно видеть только аннотированные теги, потому что именно они содержат метаданные и сообщения. Git tag сам по себе не делает такого различия в выводе, поэтому используем git for-each-ref и фильтрацию по типу объекта.

Аннотированные теги — это объекты типа tag, легковесные — просто ссылки на commit. Мы можем отфильтровать по типу:

git for-each-ref refs/tags --format="%(objecttype) %(refname:short)"

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

git for-each-ref refs/tags --format="%(objecttype) %(refname:short)"
# Показывает тип объекта (commit или tag) и имя тега
# Если objecttype = tag, то это аннотированный тег

Теперь вы можете, например, вывести только аннотированные теги с сообщением:

git for-each-ref refs/tags --sort=-creatordate \
  --format="%(objecttype) %(refname:short)  %(creatordate:short)  %(subject)" \
  | grep "^tag "

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

# Сначала выводим тип объекта и другие поля
# Затем через grep отбираем только строки, начинающиеся с "tag "
# Таким образом остаются только аннотированные теги

Связка git tag и git log

Иногда вы хотите не просто увидеть список тегов, а еще и их расположение в истории коммитов. В этом помогает git log.

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

Очень наглядный способ:

git log --oneline --decorate --graph --all

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

git log --oneline --decorate --graph --all
# --oneline   — компактный формат "хеш сообщение"
# --decorate  — показывает пометки вида (HEAD -> main, tag: v1.0.0)
# --graph     — рисует текстовый граф веток
# --all       — показывает историю по всем веткам

В выводе вы увидите что-то вроде:

* 3a1b5c5 (tag: v1.2.0, origin/main, main) Добавлена новая функция
* 8c2d1a3 (tag: v1.1.0) Оптимизация производительности
* a7f3c9d (tag: v1.0.0) Первый стабильный релиз

Так вы сразу понимаете, на какие коммиты "навешаны" теги.

Показать только коммиты, помеченные тегами

Если вас интересуют только те коммиты, на которые указывают теги, можно использовать фильтрацию через git log и git tag --points-at.

Подход с использованием xargs:

git tag | xargs -I {} git log -1 --oneline {}

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

git tag | xargs -I {} git log -1 --oneline {}
# Для каждого тега выполняем git log -1 <tag>
# В итоге получаем список коммитов, на которые указывают теги
# с их коротким описанием

Так вы получите, по сути, "список релизных коммитов" с сообщениями.

Поиск тегов по сообщению и содержимому

Иногда вы помните только фрагмент названия или сообщения тега (например, "security fix") и хотите найти все теги, где это упоминается.

Поиск по имени тега

Это делается через шаблоны git tag -l, о которых мы уже говорили:

git tag -l "*security*"

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

git tag -l "*security*"
# Ищет теги, в имени которых есть подстрока "security"

Поиск по сообщению аннотированного тега

Здесь можно использовать git for-each-ref и фильтрацию:

git for-each-ref refs/tags --format="%(refname:short) %(contents)" \
  | grep -i "security"

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

git for-each-ref refs/tags --format="%(refname:short) %(contents)" \
  | grep -i "security"
# %(contents) — тело аннотированного тега (сообщение)
# grep -i     — ищет подстроку "security" без учета регистра
# В результате вы видите только те теги, в чьем сообщении есть это слово

Имейте в виду:

• для легковесных тегов contents будет пустым, так как у них нет собственного сообщения;
• этот метод хорошо работает, если вы дисциплинированно пишете осмысленные сообщения к аннотированным тегам (например, список изменений в релизе).

Практические сценарии использования просмотра тегов

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

Сценарий 1. Найти последний релизный тег и сравнить с текущим состоянием

Представьте, что у вас есть проект, где релизы помечаются тегами вида vX.Y.Z. Вы хотите понять:

• какой тег является последним релизом;
• какие изменения произошли с тех пор.

Шаг 1. Найти последний тег по версии

Если вы используете семантические версии (v1.0.0, v1.2.3 и т. д.), удобно отсортировать теги как версии:

git tag -l "v*" --sort=v:refname

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

git tag -l "v*" --sort=v:refname
# Сортирует теги по "версионному" порядку (не просто по алфавиту)
# Последняя строка — самый новый тег по версии

Шаг 2. Проверить последний тег

git tag -l "v*" --sort=v:refname | tail -n 1

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

git tag -l "v*" --sort=v:refname | tail -n 1
# Показывает только последний (самый "новый" по версии) тег

Шаг 3. Сравнить изменения между последним тегом и текущей веткой

LAST_TAG=$(git tag -l "v*" --sort=v:refname | tail -n 1)

git log --oneline "${LAST_TAG}..HEAD"

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

LAST_TAG=$(git tag -l "v*" --sort=v:refname | tail -n 1)
# Сохраняем имя последнего тега в переменную

git log --oneline "${LAST_TAG}..HEAD"
# Показываем список коммитов, которые были сделаны после последнего релизного тега

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

Сценарий 2. Посмотреть, какие теги уже существуют перед созданием нового

Прежде чем создавать новый тег (например, v1.3.0), удобно посмотреть, какие теги уже есть, чтобы не допустить конфликт или пропуск версии.

git tag -l "v1.*" --sort=v:refname

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

git tag -l "v1.*" --sort=v:refname
# Выводит все теги версии 1.x в порядке версий
# Можно быстро увидеть, что у вас уже есть, например, v1.0.0 v1.1.0 v1.2.0

Посмотрев на этот список, вы понимаете, что следующий логичный тег — v1.3.0.

Сценарий 3. Проверить, помечены ли важные коммиты тегами

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

Шаг 1. Посмотреть историю релизной ветки (например, main):

git log main --oneline --decorate

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

git log main --oneline --decorate
# Пометки вида (tag: v1.2.0) покажут вам, на каких коммитах висят теги

Шаг 2. Найти коммиты без тегов, которые должны были быть релизами.

Здесь уже нужна ваша доменная логика (например, по сообщениям "Release to production"). Вы можете сочетать git log с фильтром по содержимому:

git log main --oneline --decorate --grep="Release to production"

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

git log main --oneline --decorate --grep="Release to production"
# Ищет в истории коммиты, в сообщении которых есть "Release to production"
# В выводе вы сразу увидите, какие из них имеют теги (по decorate)

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

git tag -a v1.3.0 <hash> -m "Релиз версии 1.3.0"

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

git tag -a v1.3.0 <hash> -m "Релиз версии 1.3.0"
# Создаем аннотированный тег на нужный коммит по его хешу

Сценарий 4. Быстро посмотреть разницу между двумя тегами

Допустим, у вас есть два релиза: v1.1.0 и v1.2.0. Вы хотите увидеть, что изменилось между ними.

git diff v1.1.0 v1.2.0

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

git diff v1.1.0 v1.2.0
# Показывает различия в файлах между двумя тегами
# Удобно для анализа изменений между релизами

Если вы хотите увидеть только список коммитов между тегами:

git log --oneline v1.1.0..v1.2.0

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

git log --oneline v1.1.0..v1.2.0
# Список коммитов, которые есть в v1.2.0, но отсутствуют в v1.1.0

Заключение

Команда git tag сама по себе довольно проста, если рассматривать только базовое использование. Но в связке с другими инструментами Git — git show, git log, git for-each-ref, git describe — вы получаете мощный набор возможностей для анализа истории релизов и версий.

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

• git tag без параметров — список локальных тегов;
• git tag -l "шаблон" — фильтрация тегов по имени;
• git show — подробности по тегу и связанному коммиту;
• git tag --points-at — найти теги, указывающие на коммит;
• git fetch --tags — получить теги с удаленного репозитория;
• git for-each-ref refs/tags — гибкое форматирование и сортировка списка тегов;
• git describe --tags — получить человекочитаемое описание коммита на основе ближайшего тега.

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

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

Как удалить тег локально и на удаленном и проверить результат

1. Удалить локальный тег:

git tag -d v1.0.0
# Удаляем тег v1.0.0 из локального репозитория

2. Удалить тег на удаленном:

git push origin :refs/tags/v1.0.0
# Отправляем "пустую" ссылку вместо тега - так он удаляется на origin

3. Проверить, что тега больше нет:

git tag -l "v1.0.0"        # Локально
git ls-remote --tags origin | grep v1.0.0  # На удаленном

Почему git describe не находит теги и как это проверить

Частая ситуация — git describe --tags ничего не выводит или выдает только хеш без тега.

Проверьте:

git tag -l
# Убедитесь, что в репозитории вообще есть теги

git describe --tags --debug
# Показывает, как Git ищет ближайший тег и почему может его не находить

Если теги есть, но git describe их игнорирует, возможно, они созданы как легковесные и находятся "далеко" в истории. Попробуйте создать аннотированный тег ближе к текущим коммитам.

Как увидеть, на какой именно объект указывает тег (commit или tag)

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

git for-each-ref refs/tags --format="%(refname:short) %(objecttype)"
# Покажет имя тега и тип объекта (commit или tag)

Если тип — tag, значит, это аннотированный тег (объект tag, который указывает на commit).

Как вывести список тегов с хешами коммитов в одной строке

Чтобы сразу видеть, на какой хеш указывает каждый тег:

git show-ref --tags
# Показывает строки вида:
# <hash> refs/tags/<tagname>

Если хотите более компактно:

git for-each-ref refs/tags --format="%(refname:short) %(objectname:short)"
# tagname short-hash

Как показать только теги, которые содержат коммиты текущей ветки

Иногда нужно увидеть теги, "достижимые" из текущей ветки, то есть лежащие в ее истории:

git tag --merged HEAD
# Показывает теги, которые указывают на коммиты, входящие в историю HEAD

git tag --no-merged HEAD
# Наоборот - теги, которые не входят в историю текущей ветки

Так вы быстро понимаете, какие релизы уже включены в вашу ветку, а какие нет.