Теги и релизы

Updated Jul 2026

Почему теги важны для QA

Теги отмечают конкретные точки в истории Git — как правило, релизы. Для QA-инженеров теги создают аудиторский след: какой коммит был выпущен, что было протестировано и каковы были результаты тестирования. Когда клиент сообщает о баге в «версии 2.4.0», вы можете переключиться на этот тег и воспроизвести проблему.

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

Легковесные теги

Легковесный тег — это просто указатель на коммит. Он не содержит дополнительных метаданных.

# Create a lightweight tag
git tag v2.4.0

# Tag a specific commit (not HEAD)
git tag v2.4.0 abc123f

Аннотированные теги (рекомендуется)

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

# Create an annotated tag
git tag -a v2.4.0 -m "Release 2.4.0 - passed full regression suite"

# Create an annotated tag with detailed test information
git tag -a v2.4.0 -m "Release 2.4.0
Regression suite: 342/342 passed
Browser coverage: Chrome 120, Firefox 121, Safari 17
CI run: https://github.com/org/repo/actions/runs/12345
Known issues: SHOP-567 (low priority, cosmetic)"

Работа с тегами

# List all tags
git tag

# List tags matching a pattern
git tag -l "v2.4.*"

# Show tag details (annotated tags include the message)
git show v2.4.0

# Push a specific tag to remote
git push origin v2.4.0

# Push all tags
git push origin --tags

# Delete a local tag
git tag -d v2.4.0-rc1

# Delete a remote tag
git push origin --delete v2.4.0-rc1

# Checkout a specific tag (detached HEAD state)
git checkout v2.4.0

# Create a branch from a tag (for hotfixes)
git checkout -b hotfix/2.4.1 v2.4.0

Семантическое версионирование

Большинство проектов используют семантическое версионирование (SemVer): MAJOR.MINOR.PATCH

Предрелизные теги указывают на версии, которые ещё не стабильны:

git tag -a v2.4.0-rc1 -m "Release candidate 1 for 2.4.0"
git tag -a v2.4.0-beta.1 -m "Beta 1 for 2.4.0"
git tag -a v2.4.0-alpha.3 -m "Alpha 3 for 2.4.0"

QA и версионирование

Привязка результатов тестирования к релизам

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

В сообщении тега

git tag -a v2.4.0 -m "Release 2.4.0

Test Results:
  Unit tests: 1,247/1,247 passed
  Integration tests: 89/89 passed
  Browser tests: 342/342 passed (Chrome 120, Firefox 121, Safari 17)
  Visual regression: 0 diffs detected
  Performance: LCP 1.2s (budget: 2.5s), FID 45ms (budget: 100ms)

CI Run: https://github.com/org/repo/actions/runs/12345
Test Report: https://qa-reports.example.com/releases/2.4.0

Known Issues:
  SHOP-567: Tooltip misalignment on mobile (low priority)
  SHOP-589: Slow search on large datasets (medium, fix planned for 2.5.0)"

В GitHub Releases

GitHub Releases предоставляют более богатый интерфейс, чем сырые теги. Можно добавить форматированные заметки к релизу, прикрепить бинарные артефакты и отметить предрелизы.

# Create a GitHub release from a tag
gh release create v2.4.0 \
  --title "Release 2.4.0" \
  --notes "## What's New
- Redesigned checkout flow
- Added PayPal support
- Fixed 12 bugs from 2.3.x

## Test Results
- Full regression: 342/342 passed
- [CI Run](https://github.com/org/repo/actions/runs/12345)
- [Test Report](https://qa-reports.example.com/releases/2.4.0)

## Known Issues
- SHOP-567: Tooltip misalignment on mobile"

В CI/CD-пайплайне (автоматизированно)

Лучший подход: автоматизировать создание тегов релиза как часть пайплайна.

# Tag and release after all tests pass
create-release:
  needs: [unit-tests, integration-tests, browser-tests]
  if: github.ref == 'refs/heads/main' && github.event_name == 'push'
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4

    - name: Determine version
      id: version
      run: echo "VERSION=$(cat package.json | jq -r .version)" >> $GITHUB_OUTPUT

    - name: Create tag
      run: |
        git tag -a "v${{ steps.version.outputs.VERSION }}" \
          -m "Release ${{ steps.version.outputs.VERSION }} - all tests passed"
        git push origin "v${{ steps.version.outputs.VERSION }}"

Релизный рабочий процесс для QA

Типичный рабочий процесс релиза с участием QA:

1. Заморозка фич: никаких новых фич в ветке релиза. Только исправления багов.
2. Полная регрессия: выполнение полного набора тестов (автоматизированных + ручное исследовательское тестирование).
3. Документирование результатов: обновление чеклиста релиза с результатами тестирования.
4. Создание тега релиз-кандидата: v2.4.0-rc1
5. Развёртывание RC на staging: дымовое тестирование в окружении, приближенном к продакшену.
6. Приёмка: QA одобряет релиз на основе определённых критериев.
7. Создание тега релиза: v2.4.0 с метаданными результатов тестирования.
8. Развёртывание в продакшен: запуск дымовых тестов после развёртывания.
9. Мониторинг: наблюдение за частотой ошибок и метриками производительности в течение 24-48 часов.

Сравнение релизов

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

# See all commits between two releases
git log v2.3.0..v2.4.0 --oneline

# See the diff between two releases
git diff v2.3.0..v2.4.0

# See which files changed
git diff v2.3.0..v2.4.0 --stat

# See commits that touched test files
git log v2.3.0..v2.4.0 -- tests/

Это помогает вам ответить на вопрос: «Что изменилось с последнего релиза?» — первый вопрос в любой сессии планирования регрессионного тестирования.

Практическое упражнение

1. Создайте аннотированный тег для «релиза» с метаданными результатов тестирования в сообщении
2. Запушьте тег и создайте GitHub Release с форматированными заметками к релизу
3. Потренируйтесь в переключении на тег и создании ветки хотфикса от него
4. Используйте git log v1..v2 для сравнения двух релизов и определения, что нуждается в регрессионном тестировании
5. Настройте автоматическое создание тега релиза в CI-пайплайне, запускающееся после прохождения всех тестов
6. Напишите чеклист приёмки релиза, который ваша команда сможет использовать для каждого релиза