Как работает pre-release ветка и зачем она нужна?

Pre-release ветка (часто называемая release или release/*) — это ключевой элемент в стратегиях ветвления, таких как Git Flow. Её основная цель — создать изолированное пространство для подготовки конкретной версии продукта к выпуску, отделив этот процесс от текущей разработки новых функций.

Как это работает

Когда команда решает, что накопленный в ветке разработки (например, develop) функционал готов к выпуску, создаётся новая ветка от develop, обычно с именем release/v1.2.0. С этого момента:

• В эту ветку вносятся только исправления багов, найденных во время тестирования релиз-кандидата.
• Разработка новых функций продолжается в develop и не попадает в release-ветку.
• На основе этой ветки запускаются extended-тесты, сборка финальных артефактов (docker-образы, установочные пакеты) и подготовка документации.

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

В CI/CD пайплайне можно настроить автоматическую сборку и развёртывание на staging-окружение именно для веток, начинающихся с release/. Это позволяет командам QA и product-менеджерам тестировать именно ту версию, которая скоро выйдет.

# Пример создания и работы с pre-release веткой в Git
# 1. Создаём ветку релиза от develop
git checkout develop
git pull origin develop
git checkout -b release/v1.5.0

# 2. Вносим исправления, найденные при тестировании (только багфиксы)
git commit -m "fix: resolve issue with login timeout"

# 3. Когда релиз готов, сливаем ветку в main (production) и обратно в develop
git checkout main
git merge --no-ff release/v1.5.0
git tag -a v1.5.0 -m "Release version 1.5.0"

git checkout develop
git merge --no-ff release/v1.5.0

# 4. Удаляем временную ветку релиза
git branch -d release/v1.5.0

Такой подход гарантирует, что тег в main соответствует собранному и протестированному артефакту, а все исправления, сделанные во время подготовки релиза, возвращаются в основную ветку разработки (develop).

Итог: Pre-release ветка — это инструмент для контроля качества и стабилизации версии перед выпуском. Её стоит применять в проектах с регулярными релизами, где важно чёткое разделение этапов разработки, тестирования и поставки.