Release Branch в Git — что это, назначение и процесс работы

Что такое Release Branch в Git

Release Branch (ветка релиза) — это временная ветка в Git Flow, создаваемая от develop, когда команда решает, что текущий набор функций готов к выпуску. Она существует ровно столько, сколько длится финальная подготовка релиза — от нескольких часов до нескольких дней.

Основное назначение release ветки — заморозить конкретный набор функций для релиза, не останавливая разработку следующих версий. Пока release ветка готовится к выпуску, другие разработчики могут продолжать сливать feature ветки в develop для следующего релиза.

В release ветке не создаются новые функции — только исправления багов, обновление версии приложения, локализация и документация. После завершения всех работ release ветка сливается в main (маркируется как релиз) и обратно в develop (чтобы багфиксы попали в будущие версии).

По данным Atlassian, 2024, release ветки критически важны для проектов с регулярными релизными циклами — они обеспечивают предсказуемость и стабильность процесса выпуска.

Жизненный цикл release ветки

Жизненный цикл release ветки от создания до удаления включает несколько этапов. Понимание каждого этапа помогает команде синхронизировать действия и избежать ошибок.

1. Создание — от последнего коммита develop создаётся ветка с именем release/2.5.0. develop продолжает принимать feature ветки для следующей версии.
2. Подготовка — в release ветке обновляется версия приложения в build.gradle, Info.plist и других конфигурационных файлах.
3. Багфиксинг — исправляются критические ошибки, найденные в процессе финального тестирования. Только баги — никаких новых функций.
4. Финальное тестирование — QA-команда проводит регрессионное тестирование на release ветке. Новые баги отправляются на исправление в ту же ветку.
5. Слияние в main — release ветка сливается в main с флагом --no-ff. Создаётся тег релиза: v2.5.0.
6. Слияние в develop — release ветка сливается обратно в develop, чтобы багфиксы из релиза попали в текущую разработку.
7. Удаление — release ветка удаляется локально и удалённо, так как её задача выполнена.

Пункт 6 — обратное слияние в develop — часто забывают, но он критически важен. Без него багфиксы, сделанные в release, не попадут в develop, и в следующем релизе те же ошибки могут проявиться снова.

Типичные длительности этапов release ветки

Время жизни release ветки зависит от сложности релиза и качества кода в develop. В среднем подготовка занимает от 2 до 5 рабочих дней для мобильного приложения среднего размера.

Что делается в release ветке

В release ветке выполняется строго ограниченный набор задач. Любое отклонение от этого списка нарушает модель Git Flow и создаёт риски для стабильности релиза.

Правило запрета новых функций — самое важное в release ветке. Если функция не успела к релизу, она ждёт следующего цикла. Попытка протолкнуть незавершённую функцию в release ветку — главная причина срывов дедлайнов и багов в продакшене.

Обновление версии в мобильном проекте

В release ветке обязательно обновляется номер версии приложения. Для Android это поля versionCode и versionName в build.gradle, для iOS — CFBundleShortVersionString в Info.plist.

// build.gradle (app-level) — обновление версии в release ветке
android {
    defaultConfig {
        versionCode 42
        versionName "2.5.0"
    }
}

// Для iOS — обновление Info.plist
// CFBundleShortVersionString = 2.5.0
// CFBundleVersion = 42

Отличия release от hotfix

Начинающие разработчики часто путают release и hotfix ветки, хотя их назначение принципиально разное. Ошибка в выборе типа ветки может привести к задержке критического исправления или нарушению процесса релиза.

• Источник — release создаётся от develop, hotfix — от main. Это главное отличие, которое определяет всё остальное.
• Срочность — release плановый: команда сама решает, когда начать подготовку. Hotfix экстренный: проблема в продакшене требует немедленного исправления.
• Содержимое — release может включать несколько исправлений и обновление версии. Hotfix содержит только одно критическое исправление.
• Слияние — release сливается в main и develop. Hotfix также сливается в main и develop, но в приоритетном порядке.
• Время жизни — release живёт от 1 до 7 дней. Hotfix живёт от 30 минут до 1 дня.

Если ошибка обнаружена в процессе подготовки релиза (в release ветке) — это обычный багфикс. Если ошибка обнаружена в продакшене (на main) — это hotfix, и он создаётся от main, даже если release ветка уже существует.

Правила именования release веток

Единый стандарт именования release веток упрощает навигацию по репозиторию и позволяет CI/CD системам автоматически определять, что ветка относится к релизному процессу.

• release/X.Y.Z — стандартный формат Git Flow, где X.Y.Z — версия релиза. Пример: release/2.5.0.
• release/название — альтернативный формат с кодовым именем релиза. Пример: release/merlin.
• release/дата — формат с датой релиза. Используется редко, так как версия важнее даты. Пример: release/2024-12-01.

Формат release/X.Y.Z — предпочтительный, так как он явно связывает ветку с номером версии, который будет присвоен релизу. Это упрощает поиск и автоматическую обработку скриптами CI/CD.

Стратегия обратного слияния в develop

Обратное слияние (merge back) release ветки в develop — одна из самых важных и одновременно часто пропускаемых операций. Без неё все багфиксы, сделанные в release, останутся только в релизной версии и не попадут в следующий релизный цикл.

Процесс обратного слияния выполняется после того, как release ветка уже слита в main. Сначала release сливается в develop, затем — удаляется. Это гарантирует, что develop содержит все исправления, сделанные в процессе подготовки релиза.

После обратного слияния возможны конфликты — особенно если в develop уже появились новые feature ветки, которые изменяли те же файлы. Разработчик, ответственный за релиз, разрешает эти конфликты и пушит develop на сервер.

Некоторые команды используют rebase вместо merge для обратного слияния, чтобы история оставалась линейной. Однако merge более безопасен для develop, так как не переписывает историю коммитов, которые уже могли быть использованы другими разработчиками.

Примеры команд для работы с release

Рассмотрим полный цикл работы с release веткой: от создания до удаления после успешного релиза мобильного приложения версии 2.5.0.

# 1. Создание release ветки от develop
git checkout develop
git pull origin develop
git checkout -b release/2.5.0

# 2. Обновление версии и багфиксы
git add build.gradle
git commit -m "Bump version to 2.5.0"

# 3. Исправление багов (только bugfixes)
git add src/fix/
git commit -m "Fix crash on payment screen"

# 4. Отправка release ветки на сервер
git push origin release/2.5.0

# 5. Слияние release в main
git checkout main
git pull origin main
git merge --no-ff release/2.5.0
git tag -a v2.5.0 -m "Release 2.5.0"
git push origin main --tags

# 6. Обратное слияние в develop
git checkout develop
git merge --no-ff release/2.5.0
git push origin develop

# 7. Удаление release ветки
git branch -d release/2.5.0
git push origin --delete release/2.5.0

Команды 5 и 6 — двойное слияние — критически важны. Сначала main получает релизный код и тег, затем develop синхронизируется с багфиксами из release. Если пропустить шаг 6, исправления из релиза не попадут в следующий цикл разработки.

Автоматизация релизного процесса

Для мобильных проектов с регулярными релизами процесс создания release ветки и обновления версии можно автоматизировать через CI/CD скрипты. GitHub Actions позволяет создать workflow, который при нажатии на кнопку создаёт release ветку с автоматическим обновлением версии.

Для мобильных проектов с регулярными релизами процесс создания release ветки и обновления версии можно автоматизировать через CI/CD скрипты. GitHub Actions позволяет создать workflow, который при нажатии на кнопку создаёт release ветку с автоматическим обновлением версии.

# GitHub Actions — автоматизация создания release ветки
name: Create Release Branch

on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Release version (e.g. 2.5.0)'
        required: true

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Create release branch
        run: |
          git checkout develop
          git checkout -b release/${{ inputs.version }}
          git push origin release/${{ inputs.version }}