Git Tag: разметка релизов и закладки в истории
Git Tag: разметка релизов и закладки в истории
Теги — это механизм Git для присвоения осмысленных меток конкретным коммитам. В отличие от веток, теги не двигаются: они зафиксированы в точке коммита и служат якорями для релизов, версий и важных контрольных точек. Без тегов релизная история превращается в поиск по хешам — и это прямой путь к ошибкам деплоя.
Типы тегов: lightweight vs annotated
Существует два типа тегов. Lightweight — это просто имя, привязанное к коммиту, без дополнительных метаданных. Annotated — полноценный объект Git с автором, датой, сообщением и возможностью подписи.
Для релизов всегда используйте annotated теги. Lightweight не содержат метаданных и не подписываются — при аудите или откате вы потеряете контекст.
| Свойство | Lightweight | Annotated |
|---|---|---|
| Объект в базе | Нет | Да (объект tag) |
| Сообщение | Нет | Да |
| Автор/дата | Нет | Да |
| GPG-подпись | Нет | Да |
| Скорость создания | Быстрее | Чуть медленнее |
Создание, просмотр и удаление тегов
Создание annotated тега:
Создание lightweight тега:
Просмотр всех тегов:
Просмотр деталей конкретного annotated тега:
Удаление локального тега:
Список тегов по шаблону:
Флаг -l поддерживает glob-шаблоны. Это быстрее, чем гонять grep по выводу git tag.
Отправка тегов в remote
По умолчанию git push не отправляет теги. Это частая причина того, что коллеги не видят релизный тег на удалённом репозитории.
Отправка одного тега:
Отправка всех локальных тегов:
Удаление тега на remote:
Локальное удаление и удаление на remote — это две разные операции. Забыть выполнить вторую — типичная ошибка при откате релиза.
Подписание тегов GPG
Annotated теги можно подписать GPG-ключом. Это гарантирует, что тег был создан конкретным автором и не был подменён.
Предварительно убедитесь, что GPG-ключ настроен:
Создание подписанного тега:
Проверка подписи:
Если git tag -v выдаёт ошибку «no signature found», тег не подписан. Если «Good signature from…» — подпись валидна. Убедитесь, что публичный ключ автора доступен в вашем keyring.
Работа с тегами в CI/CD пайплайнах
В пайплайнах теги — основной триггер для релизов. Большинство систем CI/CD позволяют фильтровать ветки и теги.
Пример для GitHub Actions:
Пример для GitLab CI:
Полезные команды для использования внутри пайплайна:
Всегда используйте fetch-tags: true в шаге checkout. Без этого пайплайн может не увидеть теги и сломаться фильтр по $CI_COMMIT_TAG.
Теги — минимальный инструмент с максимальным эффектом. Annotated с подписями GPG, отправка --tags при релизе, фильтрация по паттерну v* в CI — этого набора достаточно, чтобы релизная история оставалась читаемой и проверяемой.
Задача: написать IT-заметку для блога Lead DevOps на тему Git Tag. Формат: markdown тело