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 — често се забравя, но е критично важно. Без него поправките на бъгове, направени в release, няма да попаднат в 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 — една от най-важните и същевременно често пропускани операции. Без него всички поправки на бъгове, направени в release, остават само във версията на релиза и не попадат в следващия цикъл на издаване.

Процесът на обратно сливане се изпълнява, след като релизният клон вече е слят в 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 }}