Release Branch în Git — ce este, scopul și procesul de lucru

Ce este Release Branch în Git

Release Branch (ramura de lansare) — este o ramură temporară în Git Flow, creată din develop atunci când echipa decide că setul curent de funcționalități este gata pentru lansare. Există exact cât durează pregătirea finală a lansării — de la câteva ore până la câteva zile.

Scopul principal al ramurii release — să înghețe un set specific de funcționalități pentru lansare, fără a opri dezvoltarea versiunilor următoare. În timp ce ramura release se pregătește pentru lansare, alți dezvoltatori pot continua să îmbine ramurile feature în develop pentru următoarea lansare.

În ramura release nu se creează funcționalități noi — doar corecturi de bug-uri, actualizarea versiunii aplicației, localizare și documentație. După finalizarea tuturor lucrărilor, ramura release este îmbinată în main (marcată ca lansare) și înapoi în develop (pentru ca corecturile de bug-uri să ajungă în versiunile viitoare).

Conform Atlassian, 2024, ramurile release sunt critic de importante pentru proiectele cu cicluri regulate de lansare — ele asigură predictibilitatea și stabilitatea procesului de lansare.

Ciclul de viață al ramurii release

Ciclul de viață al ramurii release, de la creare până la ștergere, include mai multe etape. Înțelegerea fiecărei etape ajută echipa să sincronizeze acțiunile și să evite erorile.

1. Creare — de la ultimul commit din develop se creează o ramură cu numele release/2.5.0. develop continuă să accepte ramuri feature pentru versiunea următoare.
2. Pregătire — în ramura release se actualizează versiunea aplicației în build.gradle, Info.plist și alte fișiere de configurare.
3. Corectare bug-uri — se repară bug-urile critice găsite în procesul de testare finală. Doar bug-uri — fără funcționalități noi.
4. Testare finală — echipa QA efectuează testare de regresie pe ramura release. Bug-urile noi sunt trimise spre corectare în aceeași ramură.
5. Îmbinare în main — ramura release este îmbinată în main cu flag-ul --no-ff. Se creează tag-ul de lansare: v2.5.0.
6. Îmbinare în develop — ramura release este îmbinată înapoi în develop, pentru ca corecturile de bug-uri din lansare să ajungă în dezvoltarea curentă.
7. Ștergere — ramura release este ștearsă local și la distanță, deoarece sarcina sa a fost îndeplinită.

Punctul 6 — îmbinarea inversă în develop — este adesea uitat, dar este critic de important. Fără el, corecturile de bug-uri făcute în release nu vor ajunge în develop, iar în următoarea lansare aceleași erori pot apărea din nou.

Duratele tipice ale etapelor ramurii release

Timpul de viață al ramurii release depinde de complexitatea lansării și de calitatea codului în develop. În medie, pregătirea durează între 2 și 5 zile lucrătoare pentru o aplicație mobilă de dimensiuni medii.

Ce se face în ramura release

În ramura release se execută un set strict limitat de sarcini. Orice abatere de la această listă încalcă modelul Git Flow și creează riscuri pentru stabilitatea lansării.

Regula interzicerii funcționalităților noi — cea mai importantă în ramura release. Dacă o funcționalitate nu a apucat lansarea, așteaptă următorul ciclu. Încercarea de a împinge o funcționalitate neterminată în ramura release — principala cauză a întârzierilor termenelor și a bug-urilor în producție.

Actualizarea versiunii în proiectul mobil

În ramura release se actualizează obligatoriu numărul versiunii aplicației. Pentru Android sunt câmpurile versionCode și versionName în build.gradle, pentru iOS — CFBundleShortVersionString în Info.plist.

// build.gradle (app-level) — actualizarea versiunii în ramura release
android {
    defaultConfig {
        versionCode 42
        versionName "2.5.0"
    }
}

// Pentru iOS — actualizarea Info.plist
// CFBundleShortVersionString = 2.5.0
// CFBundleVersion = 42

Diferențele dintre release și hotfix

Dezvoltatorii începători confundă adesea ramurile release și hotfix, deși scopul lor este fundamental diferit. O eroare în alegerea tipului de ramură poate duce la întârzierea unei corecturi critice sau la perturbarea procesului de lansare.

• Sursa — release se creează din develop, hotfix — din main. Aceasta este principala diferență care determină tot restul.
• Urgența — release este planificat: echipa decide singură când să înceapă pregătirea. Hotfix este de urgență: o problemă în producție necesită o remediere imediată.
• Conținutul — release poate include mai multe corecturi și actualizarea versiunii. Hotfix conține doar o singură corectură critică.
• Îmbinarea — release se îmbină în main și develop. Hotfix se îmbină și el în main și develop, dar în mod prioritar.
• Timpul de viață — release trăiește între 1 și 7 zile. Hotfix trăiește între 30 de minute și 1 zi.

Dacă o eroare este descoperită în procesul de pregătire a lansării (în ramura release) — este o corectură obișnuită de bug. Dacă eroarea este descoperită în producție (pe main) — este hotfix și se creează din main, chiar dacă ramura release există deja.

Reguli de denumire a ramurilor release

Un standard unitar de denumire a ramurilor release simplifică navigarea prin depozit și permite sistemelor CI/CD să determine automat că ramura aparține procesului de lansare.

• release/X.Y.Z — formatul standard Git Flow, unde X.Y.Z este versiunea lansării. Exemplu: release/2.5.0.
• release/nume — format alternativ cu numele de cod al lansării. Exemplu: release/merlin.
• release/data — format cu data lansării. Folosit rar, deoarece versiunea este mai importantă decât data. Exemplu: release/2024-12-01.

Formatul release/X.Y.Z — preferat, deoarece leagă explicit ramura de numărul versiunii care va fi atribuit lansării. Aceasta simplifică căutarea și procesarea automată prin scripturile CI/CD.

Strategia de îmbinare inversă în develop

Îmbinarea inversă (merge back) a ramurii release în develop — una dintre cele mai importante și, în același timp, adesea omise operații. Fără ea, toate corecturile de bug-uri făcute în release rămân doar în versiunea lansată și nu ajung în următorul ciclu de lansare.

Procesul de îmbinare inversă se execută după ce ramura release a fost deja îmbinată în main. Mai întâi release se îmbină în develop, apoi — se șterge. Aceasta garantează că develop conține toate corecturile făcute în procesul de pregătire a lansării.

După îmbinarea inversă sunt posibile conflicte — mai ales dacă în develop au apărut deja ramuri feature noi care au modificat aceleași fișiere. Dezvoltatorul responsabil pentru lansare rezolvă aceste conflicte și trimite develop pe server.

Unele echipe folosesc rebase în loc de merge pentru îmbinarea inversă, pentru ca istoricul să rămână liniar. Totuși, merge este mai sigur pentru develop, deoarece nu rescrie istoricul commit-urilor care ar putea fi deja folosite de alți dezvoltatori.

Exemple de comenzi pentru lucrul cu release

Să analizăm ciclul complet de lucru cu ramura release: de la creare până la ștergere după lansarea cu succes a aplicației mobile versiunea 2.5.0.

# 1. Crearea ramurii release din develop
git checkout develop
git pull origin develop
git checkout -b release/2.5.0

# 2. Actualizarea versiunii și corecturi de bug-uri
git add build.gradle
git commit -m "Bump version to 2.5.0"

# 3. Repararea bug-urilor (doar bugfixes)
git add src/fix/
git commit -m "Fix crash on payment screen"

# 4. Trimiterea ramurii release pe server
git push origin release/2.5.0

# 5. Îmbinarea release în 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. Îmbinarea inversă în develop
git checkout develop
git merge --no-ff release/2.5.0
git push origin develop

# 7. Ștergerea ramurii release
git branch -d release/2.5.0
git push origin --delete release/2.5.0

Comenzile 5 și 6 — îmbinarea dublă — sunt critic de importante. Mai întâi main primește codul lansării și tag-ul, apoi develop se sincronizează cu corecturile de bug-uri din release. Dacă se omite pasul 6, corecturile din lansare nu ajung în următorul ciclu de dezvoltare.

Automatizarea procesului de lansare

Pentru proiectele mobile cu lansări regulate, procesul de creare a ramurii release și actualizare a versiunii poate fi automatizat prin scripturi CI/CD. GitHub Actions permite crearea unui workflow care, la apăsarea unui buton, creează o ramură release cu actualizarea automată a versiunii.

Pentru proiectele mobile cu lansări regulate, procesul de creare a ramurii release și actualizare a versiunii poate fi automatizat prin scripturi CI/CD. GitHub Actions permite crearea unui workflow care, la apăsarea unui buton, creează o ramură release cu actualizarea automată a versiunii.

# GitHub Actions — automatizarea creării ramurii 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 }}