Git Tags: катим релизы через v1.0.0 без боли

Выкатка релизов через git tag — это как отправка космического корабля: нужно точно знать, какая версия кода полетит в прод. В статье разберём семантическое версионирование (v1.2.0), автоматизацию деплоя через GitHub Actions и как избежать хаоса в тегах.

Вы только что замержили фичу в main и думаете:
«Как бы это красиво упаковать в релиз?»
Ответ — git tag. Но сначала — немного теории.

🧠 Теория: Semantic Versioning (SemVer)

Формат MAJOR.MINOR.PATCH — это не просто цифры:

Часть	Когда увеличивать?	Пример
MAJOR	Ломающие изменения API	v1 → v2
MINOR	Новый функционал (без поломок)	v1.1 → v1.2
PATCH	Багфиксы	v1.2.0 → v1.2.1

Антипаттерн:
v1.2.3.4-hotfix-beta — так делать не надо.

🔧 Практика: создаём тег

# Проверяем текущую версию
git tag -l | sort -V

# Создаём новый тег (аннотированный!)
git tag -a v1.2.0 -m "Релиз: добавлен платежный шлюз"

# Пушим тег на сервер
git push origin v1.2.0

Важно:
Теги — это не ветки. Они указывают на конкретный коммит и неизменяемы (как памятники).

🤖 Автоматизируем через GitHub Actions

Пример workflow .github/workflows/deploy-on-tag.yml:

name: Deploy on Tag

on:
  push:
    tags:
      - 'v*' # Триггеримся на теги вида v1.2.0

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Extract version
        run: echo "VERSION=${GITHUB_REF#refs/tags/}" >> $GITHUB_ENV
      
      - name: Deploy to production
        run: |
          echo "Деплоим версию $VERSION"
          ./deploy.sh $VERSION

Фишка:
Можно добавить проверки (test, build) перед деплоем.

💣 Опасные моменты

Перезапись тегов
```
git tag -f v1.2.0  # Так нельзя!
```
Это как переименовать уже отправленную посылку — получатель (CI) запутается.
Теги из feature-веток
Тег должен ставиться только на стабильный main/release.
Отсутствие чистой истории
Если в main есть недоделанные коммиты — тегировать нельзя.

🎛️ Продвинутые сценарии

Пререлизные версии

git tag -a v1.2.0-rc.1 -m "Release Candidate 1"

Генерация CHANGELOG

Используйте git-chglog для автоматического формирования списка изменений между тегами.

🧪 Тестируем стратегию

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

# Сымитируйте тег локально
git tag -a v0.0.0-test -m "Test tag"
git push origin v0.0.0-test

# Убедитесь, что CI корректно обработал его

🎤 Что сказать на интервью?

— Почему выбрали деплой через теги?

Плюсы:
✅ Чёткую версию в прод
✅ Автоматическую триггеризацию деплоя
✅ Возможность отката к любому тегу

🧾 Вывод

Git tags — это ваш «чёрный ящик» для релизов.
Они превращают хаотичные деплои в управляемый процесс, где каждая версия — это артефакт с гарантированной стабильностью.

Теперь ваша очередь:

Настройте CI на теги
Начните с v0.1.0
Катите релизы без стресса 🚀