Release Branch у Git — що це, призначення та процес роботи

Що таке Release Branch у Git

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

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

У релізній гілці не створюються нові функції — лише виправлення багів, оновлення версії застосунку, локалізація та документація. Після завершення всіх робіт релізна гілка зливається в main (позначається як реліз) і назад у develop (щоб багфікси потрапили в майбутні версії).

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

Життєвий цикл релізної гілки

Життєвий цикл релізної гілки від створення до видалення включає кілька етапів. Розуміння кожного етапу допомагає команді синхронізувати дії та уникнути помилок.

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

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

Типові тривалості етапів релізної гілки

Час життя релізної гілки залежить від складності релізу та якості коду в develop. У середньому підготовка займає від 2 до 5 робочих днів для мобільного застосунку середнього розміру.

Що робиться в релізній гілці

У релізній гілці виконується суворо обмежений набір завдань. Будь-яке відхилення від цього списку порушує модель Git Flow і створює ризики для стабільності релізу.

Правило заборони нових функцій — найважливіше в релізній гілці. Якщо функція не встигла до релізу, вона чекає наступного циклу. Спроба проштовхнути незавершену функцію в релізну гілку — головна причина зриву дедлайнів і багів у продакшені.

Оновлення версії в мобільному проєкті

У релізній гілці обов'язково оновлюється номер версії застосунку. Для Android це поля versionCode і versionName у build.gradle, для iOS — CFBundleShortVersionString в Info.plist.

// build.gradle (app-level) — оновлення версії в релізній гілці
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 дня.

Якщо помилка виявлена в процесі підготовки релізу (у релізній гілці) — це звичайний багфікс. Якщо помилка виявлена в продакшені (на main) — це hotfix, і він створюється від main, навіть якщо релізна гілка вже існує.

Правила іменування релізних гілок

Єдиний стандарт іменування релізних гілок спрощує навігацію по репозиторію та дозволяє 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) релізної гілки в develop — одна з найважливіших і одночасно часто пропущених операцій. Без неї всі багфікси, зроблені в релізі, залишаться лише в релізній версії та не потраплять у наступний релізний цикл.

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

Після зворотного злиття можливі конфлікти — особливо якщо в develop вже з'явилися нові feature гілки, які змінювали ті самі файли. Розробник, відповідальний за реліз, вирішує ці конфлікти та пушить develop на сервер.

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

Приклади команд для роботи з release

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

# 1. Створення релізної гілки від 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. Відправка релізної гілки на сервер
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. Видалення релізної гілки
git branch -d release/2.5.0
git push origin --delete release/2.5.0

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

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

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

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

# GitHub Actions — автоматизація створення релізної гілки
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 }}