Release Branch w Git — co to jest, przeznaczenie i proces pracy

Czym jest Release Branch w Git

Release Branch (gałąź wydania) — to tymczasowa gałąź w Git Flow, tworzona z develop, gdy zespół decyduje, że bieżący zestaw funkcji jest gotowy do wydania. Istnieje dokładnie tak długo, jak trwa końcowe przygotowanie wydania — od kilku godzin do kilku dni.

Głównym przeznaczeniem gałęzi release jest zamrożenie konkretnego zestawu funkcji dla wydania, bez zatrzymywania rozwoju kolejnych wersji. Podczas gdy gałąź release jest przygotowywana do publikacji, inni programiści mogą kontynuować scalanie gałęzi feature z develop dla następnego wydania.

W gałęzi release nie tworzy się nowych funkcji — tylko poprawki błędów, aktualizacja wersji aplikacji, lokalizacja i dokumentacja. Po zakończeniu wszystkich prac gałąź release jest scalana z main (oznaczana jako wydanie) i z powrotem do develop (aby poprawki błędów trafiły do przyszłych wersji).

Według Atlassian, 2024, gałęzie release są krytycznie ważne dla projektów z regularnymi cyklami wydawniczymi — zapewniają przewidywalność i stabilność procesu publikacji.

Cykl życia gałęzi release

Cykl życia gałęzi release od utworzenia do usunięcia obejmuje kilka etapów. Zrozumienie każdego etapu pomaga zespołowi synchronizować działania i unikać błędów.

1. Utworzenie — od ostatniego commita develop tworzona jest gałąź o nazwie release/2.5.0. develop nadal przyjmuje gałęzie feature dla następnej wersji.
2. Przygotowanie — w gałęzi release aktualizowana jest wersja aplikacji w build.gradle, Info.plist i innych plikach konfiguracyjnych.
3. Poprawianie błędów — naprawiane są krytyczne błędy znalezione podczas końcowych testów. Tylko błędy — żadnych nowych funkcji.
4. Testy końcowe — zespół QA przeprowadza testy regresyjne na gałęzi release. Nowe błędy są wysyłane do naprawy w tej samej gałęzi.
5. Scalanie z main — gałąź release jest scalana z main z flagą --no-ff. Tworzony jest tag wydania: v2.5.0.
6. Scalanie z develop — gałąź release jest scalana z powrotem do develop, aby poprawki błędów z wydania trafiły do bieżącego rozwoju.
7. Usunięcie — gałąź release jest usuwana lokalnie i zdalnie, ponieważ jej zadanie zostało wykonane.

Punkt 6 — scalanie zwrotne do develop — często jest pomijany, ale jest krytycznie ważny. Bez niego poprawki błędów wykonane w release nie trafią do develop, a w następnym wydaniu te same błędy mogą pojawić się ponownie.

Typowe czasy trwania etapów gałęzi release

Czas życia gałęzi release zależy od złożoności wydania i jakości kodu w develop. Średnio przygotowanie zajmuje od 2 do 5 dni roboczych dla aplikacji mobilnej średniej wielkości.

Co robi się w gałęzi release

W gałęzi release wykonuje się ściśle ograniczony zestaw zadań. Jakiekolwiek odstępstwo od tej listy narusza model Git Flow i stwarza ryzyko dla stabilności wydania.

Zasada zakazu nowych funkcji — najważniejsza w gałęzi release. Jeśli funkcja nie zdążyła na wydanie, czeka na następny cykl. Próba przeforsowania niedokończonej funkcji do gałęzi release — główna przyczyną opóźnień i błędów na produkcji.

Aktualizacja wersji w projekcie mobilnym

W gałęzi release obowiązkowo aktualizowany jest numer wersji aplikacji. Dla Androida są to pola versionCode i versionName w build.gradle, dla iOS — CFBundleShortVersionString w Info.plist.

// build.gradle (app-level) — aktualizacja wersji w gałęzi release
android {
    defaultConfig {
        versionCode 42
        versionName "2.5.0"
    }
}

// Dla iOS — aktualizacja Info.plist
// CFBundleShortVersionString = 2.5.0
// CFBundleVersion = 42

Różnice między release a hotfix

Początkujący programiści często mylą gałęzie release i hotfix, chociaż ich przeznaczenie jest zasadniczo różne. Błąd w wyborze typu gałęzi może prowadzić do opóźnienia krytycznej poprawki lub naruszenia procesu wydania.

• Źródło — release tworzy się z develop, hotfix — z main. To główna różnica, która determinuje wszystko inne.
• Pilność — release jest planowany: zespół sam decyduje, kiedy rozpocząć przygotowania. Hotfix jest nagły: problem na produkcji wymaga natychmiastowej naprawy.
• Zawartość — release może zawierać kilka poprawek i aktualizację wersji. Hotfix zawiera tylko jedną krytyczną poprawkę.
• Scalanie — release jest scalany z main i develop. Hotfix również jest scalany z main i develop, ale w trybie priorytetowym.
• Czas życia — release żyje od 1 do 7 dni. Hotfix żyje od 30 minut do 1 dnia.

Jeśli błąd został wykryty podczas przygotowywania wydania (w gałęzi release) — to zwykła poprawka błędu. Jeśli błąd został wykryty na produkcji (na main) — to hotfix i tworzy się go z main, nawet jeśli gałąź release już istnieje.

Zasady nazewnictwa gałęzi release

Jednolity standard nazewnictwa gałęzi release upraszcza nawigację po repozytorium i pozwala systemom CI/CD automatycznie określać, że gałąź należy do procesu wydania.

• release/X.Y.Z — standardowy format Git Flow, gdzie X.Y.Z to wersja wydania. Przykład: release/2.5.0.
• release/nazwa — alternatywny format z kryptonimem wydania. Przykład: release/merlin.
• release/data — format z datą wydania. Używany rzadko, ponieważ wersja jest ważniejsza niż data. Przykład: release/2024-12-01.

Format release/X.Y.Z — preferowany, ponieważ jawnie łączy gałąź z numerem wersji, który zostanie przypisany do wydania. Upraszcza to wyszukiwanie i automatyczne przetwarzanie przez skrypty CI/CD.

Strategia scalania zwrotnego do develop

Scalanie zwrotne (merge back) gałęzi release do develop — jedna z najważniejszych i jednocześnie często pomijanych operacji. Bez niej wszystkie poprawki błędów wykonane w release pozostaną tylko w wersji wydania i nie trafią do następnego cyklu wydawniczego.

Proces scalania zwrotnego wykonywany jest po tym, jak gałąź release została już scalona z main. Najpierw release jest scalany z develop, następnie — usuwany. Gwarantuje to, że develop zawiera wszystkie poprawki wykonane podczas przygotowywania wydania.

Po scalaniu zwrotnym możliwe są konflikty — szczególnie jeśli w develop pojawiły się już nowe gałęzie feature, które modyfikowały te same pliki. Deweloper odpowiedzialny za wydanie rozwiązuje te konflikty i wypycha develop na serwer.

Niektóre zespoły używają rebase zamiast merge do scalania zwrotnego, aby historia pozostała liniowa. Jednak merge jest bezpieczniejszy dla develop, ponieważ nie przepisuje historii commitów, które mogły już zostać wykorzystane przez innych programistów.

Przykłady poleceń do pracy z release

Rozpatrzmy pełny cykl pracy z gałęzią release: od utworzenia do usunięcia po pomyślnym wydaniu aplikacji mobilnej w wersji 2.5.0.

# 1. Utworzenie gałęzi release z develop
git checkout develop
git pull origin develop
git checkout -b release/2.5.0

# 2. Aktualizacja wersji i poprawki błędów
git add build.gradle
git commit -m "Bump version to 2.5.0"

# 3. Naprawa błędów (tylko bugfixes)
git add src/fix/
git commit -m "Fix crash on payment screen"

# 4. Wysłanie gałęzi release na serwer
git push origin release/2.5.0

# 5. Scalanie release z 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. Scalanie zwrotne do develop
git checkout develop
git merge --no-ff release/2.5.0
git push origin develop

# 7. Usunięcie gałęzi release
git branch -d release/2.5.0
git push origin --delete release/2.5.0

Polecenia 5 i 6 — podwójne scalanie — są krytycznie ważne. Najpierw main otrzymuje kod wydania i tag, następnie develop synchronizuje się z poprawkami błędów z release. Jeśli pominąć krok 6, poprawki z wydania nie trafią do następnego cyklu rozwoju.

Automatyzacja procesu wydania

Dla projektów mobilnych z regularnymi wydaniami proces tworzenia gałęzi release i aktualizacji wersji można zautomatyzować poprzez skrypty CI/CD. GitHub Actions pozwala stworzyć workflow, który po naciśnięciu przycisku tworzy gałąź release z automatyczną aktualizacją wersji.

Dla projektów mobilnych z regularnymi wydaniami proces tworzenia gałęzi release i aktualizacji wersji można zautomatyzować poprzez skrypty CI/CD. GitHub Actions pozwala stworzyć workflow, który po naciśnięciu przycisku tworzy gałąź release z automatyczną aktualizacją wersji.

# GitHub Actions — automatyzacja tworzenia gałęzi 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 }}