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 }}