Что такое git tag и зачем нужны теги?

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

Виды тегов

Основные операции

# Создать аннотированный тег
git tag -a v2.1.0 -m "Release 2.1.0"

# Создать тег для конкретного коммита
git tag -a v1.5.0 a1b2c3d -m "Ретроспективный тег для версии 1.5.0"

# Список всех тегов
git tag
git tag -l "v2.*"    # фильтр по шаблону

# Информация о теге
git show v2.1.0

# Отправить тег на удалённый сервер
git push origin v2.1.0

# Отправить все теги
git push origin --tags

# Удалить локальный тег
git tag -d v2.1.0

# Удалить тег на сервере
git push origin --delete v2.1.0

# Переключиться на тег (detached HEAD)
git checkout v2.1.0

Семантическое версионирование (Semantic Versioning)

Формат: vMAJOR.MINOR.PATCH (например, v2.1.3)

• MAJOR — несовместимые изменения API (breaking changes)
• MINOR — новая функциональность с обратной совместимостью
• PATCH — исправления багов с обратной совместимостью

git tag -a v1.0.0 -m "Initial release"
git tag -a v1.1.0 -m "Added payment module"
git tag -a v1.1.1 -m "Fixed payment calculation bug"
git tag -a v2.0.0 -m "Breaking: new API format"

Ключевые моменты

• Для релизов всегда используйте аннотированные теги (-a) — они хранят автора, дату и сообщение
• Теги не перемещаются при новых коммитах (в отличие от веток)
• git push не отправляет теги автоматически — нужен явный git push --tags или git push origin <tag>
• git checkout <tag> приводит к состоянию detached HEAD — для работы нужно создать ветку

Частые ошибки

• Забывать пушить теги — они остаются только локально
• Использовать lightweight теги для релизов — теряете информацию об авторе и дате
• Не следовать семантическому версионированию — усложняет управление зависимостями
• Перемещать уже опубликованные теги — нарушает воспроизводимость сборок

Как используется в 2026

• CI/CD пайплайны автоматически запускают сборку и деплой при создании тега (например, v* в GitHub Actions)
• Создание тегов и GitHub Releases автоматизировано через инструменты вроде semantic-release и release-please
• Conventional Commits позволяют автоматически определять следующую версию и создавать changelog
• Container-образы тегируются соответственно Git-тегам для трассируемости деплоев

На собеседовании: подчеркните разницу между lightweight и annotated тегами — для релизов всегда annotated. Покажите знание Semantic Versioning (MAJOR.MINOR.PATCH). Частый вопрос: почему git push не отправляет теги автоматически — ответ: теги независимы от веток и требуют явного git push --tags.