Release Branch a Git-ben — mi ez, célja és munkafolyamata

Mi az a Release Branch a Git-ben

Release Branch (kiadási ág) — egy ideiglenes ág a Git Flow-ban, amely a develop-ból jön létre, amikor a csapat úgy dönt, hogy a jelenlegi funkciókészlet készen áll a kiadásra. Pontosan addig létezik, amíg a végső kiadás előkészítése tart — néhány órától néhány napig.

A release ág fő célja — egy adott funkciókészlet befagyasztása a kiadáshoz, anélkül hogy leállítaná a következő verziók fejlesztését. Amíg a release ág készül a kiadásra, más fejlesztők folytathatják a feature ágak egyesítését a develop-ba a következő kiadáshoz.

A release ágban nem jönnek létre új funkciók — csak hibajavítások, az alkalmazás verziójának frissítése, lokalizáció és dokumentáció. Az összes munka befejezése után a release ág egyesítésre kerül a main-be (kiadásként megjelölve) és vissza a develop-ba (hogy a hibajavítások bekerüljenek a jövőbeli verziókba).

Atlassian, 2024 szerint a release ágak kritikus fontosságúak a rendszeres kiadási ciklusú projektek számára — biztosítják a kiadási folyamat kiszámíthatóságát és stabilitását.

A release ág életciklusa

Életciklus — a release ág létrehozásától törléséig több szakaszt foglal magában. Az egyes szakaszok megértése segíti a csapatot a műveletek szinkronizálásában és a hibák elkerülésében.

1. Létrehozás — a develop utolsó commit-jából létrejön egy ág release/2.5.0 néven. A develop továbbra is fogadja a feature ágakat a következő verzióhoz.
2. Előkészítés — a release ágban frissítésre kerül az alkalmazás verziója a build.gradle, Info.plist és egyéb konfigurációs fájlokban.
3. Hibajavítás — a végső tesztelés során talált kritikus hibák javításra kerülnek. Csak hibák — új funkciók nélkül.
4. Végső tesztelés — a QA csapat regressziós tesztelést végez a release ágon. Az új hibák javításra kerülnek ugyanabban az ágban.
5. Egyesítés a main-be — a release ág egyesítésre kerül a main-be --no-ff zászlóval. Létrejön a kiadás tag-je: v2.5.0.
6. Egyesítés a develop-ba — a release ág visszakerül a develop-ba, hogy a kiadás hibajavításai bekerüljenek a jelenlegi fejlesztésbe.
7. Törlés — a release ág törlésre kerül helyileg és távolról, mivel feladata befejeződött.

A 6. pont — visszairányú egyesítés a develop-ba — gyakran elfelejtődik, de kritikus fontosságú. Enélkül a release-ben végzett hibajavítások nem kerülnek be a develop-ba, és a következő kiadásban ugyanazok a hibák újra megjelenhetnek.

A release ág szakaszainak tipikus időtartama

A release ág élettartama a kiadás összetettségétől és a develop kódminőségétől függ. Átlagosan az előkészítés 2-5 munkanapot vesz igénybe egy közepes méretű mobilalkalmazás esetében.

Mi történik a release ágban

A release ágban szigorúan korlátozott feladatkészlet kerül végrehajtásra. Bármilyen eltérés ettől a listától megsérti a Git Flow modellt és kockázatot teremt a kiadás stabilitására.

Az új funkciók tiltása szabály — a legfontosabb a release ágban. Ha egy funkció nem ért oda a kiadásra, vár a következő ciklusra. A befejezetlen funkció release ágba való betolakodása — a határidők csúszásának és a termelési hibáknak a fő oka.

Verzió frissítése mobilprojektben

A release ágban kötelezően frissítésre kerül az alkalmazás verziószáma. Android esetében ezek a versionCode és versionName mezők a build.gradle-ben, iOS esetében — a CFBundleShortVersionString az Info.plist-ben.

// build.gradle (app-level) — verzió frissítése a release ágban
android {
    defaultConfig {
        versionCode 42
        versionName "2.5.0"
    }
}

// iOS esetében — Info.plist frissítése
// CFBundleShortVersionString = 2.5.0
// CFBundleVersion = 42

Különbségek a release és a hotfix között

A kezdő fejlesztők gyakran összekeverik a release és hotfix ágakat, bár rendeltetésük alapvetően különböző. Hiba az ág típusának kiválasztásában a kritikus javítás késleltetéséhez vagy a kiadási folyamat megzavarásához vezethet.

• Forrás — a release a develop-ból jön létre, a hotfix — a main-ből. Ez a fő különbség, amely minden mást meghatároz.
• Sürgősség — a release tervezett: a csapat maga dönti el, mikor kezdi meg az előkészítést. A hotfix sürgős: a termelési probléma azonnali javítást igényel.
• Tartalom — a release több javítást és verziófrissítést is tartalmazhat. A hotfix csak egyetlen kritikus javítást tartalmaz.
• Egyesítés — a release egyesítésre kerül a main-be és a develop-ba. A hotfix szintén egyesítésre kerül a main-be és a develop-ba, de elsőbbségi sorrendben.
• Élettartam — a release 1-7 napig él. A hotfix 30 perctől 1 napig él.

Ha egy hibát a kiadás előkészítése során (a release ágban) fedeznek fel — az egy szokásos hibajavítás. Ha egy hibát termelésben (a main-en) fedeznek fel — az hotfix, és a main-ből jön létre, még akkor is, ha a release ág már létezik.

A release ágak elnevezésének szabályai

Egységes release ágak elnevezési szabványa leegyszerűsíti a repozitóriumban való navigációt, és lehetővé teszi a CI/CD rendszerek számára, hogy automatikusan meghatározzák, hogy az ág a kiadási folyamathoz tartozik.

• release/X.Y.Z — a Git Flow szabványos formátuma, ahol X.Y.Z a kiadás verziója. Példa: release/2.5.0.
• release/név — alternatív formátum a kiadás kódnevével. Példa: release/merlin.
• release/dátum — formátum a kiadás dátumával. Ritkán használt, mivel a verzió fontosabb, mint a dátum. Példa: release/2024-12-01.

A release/X.Y.Z formátum — előnyösebb, mivel egyértelműen összeköti az ágat a kiadáshoz rendelt verziószámmal. Ez leegyszerűsíti a keresést és a CI/CD szkriptek általi automatikus feldolgozást.

Visszairányú egyesítés stratégiája a develop-ba

Visszairányú egyesítés (merge back) a release ág develop-ba — az egyik legfontosabb és egyben gyakran kihagyott művelet. Enélkül a release-ben végzett összes hibajavítás csak a kiadási verzióban marad, és nem kerül be a következő kiadási ciklusba.

A visszairányú egyesítés folyamata azután történik, hogy a release ág már egyesítésre került a main-be. Először a release egyesítésre kerül a develop-ba, majd — törlésre. Ez garantálja, hogy a develop tartalmazza a kiadás előkészítése során végzett összes javítást.

A visszairányú egyesítés után konfliktusok lehetségesek — különösen, ha a develop-ban már megjelentek új feature ágak, amelyek ugyanazokat a fájlokat módosították. A kiadásért felelős fejlesztő feloldja ezeket a konfliktusokat és push-olja a develop-ot a szerverre.

Egyes csapatok a merge helyett rebase-t használnak a visszairányú egyesítéshez, hogy a történet lineáris maradjon. Azonban a merge biztonságosabb a develop számára, mivel nem írja felül a commit-ek történetét, amelyeket más fejlesztők már használhattak.

Példák parancsokra a release-szel való munkához

Vizsgáljuk meg a release ággal való teljes munkaciklust: a létrehozástól a törlésig a 2.5.0 verziójú mobilalkalmazás sikeres kiadása után.

# 1. Release ág létrehozása a develop-ból
git checkout develop
git pull origin develop
git checkout -b release/2.5.0

# 2. Verzió frissítése és hibajavítások
git add build.gradle
git commit -m "Bump version to 2.5.0"

# 3. Hibák javítása (csak bugfixes)
git add src/fix/
git commit -m "Fix crash on payment screen"

# 4. Release ág elküldése a szerverre
git push origin release/2.5.0

# 5. Release egyesítése a main-be
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. Visszairányú egyesítés a develop-ba
git checkout develop
git merge --no-ff release/2.5.0
git push origin develop

# 7. Release ág törlése
git branch -d release/2.5.0
git push origin --delete release/2.5.0

Az 5. és 6. parancs — kettős egyesítés — kritikus fontosságú. Először a main megkapja a kiadási kódot és a tag-et, majd a develop szinkronizálódik a release hibajavításaival. Ha a 6. lépés kimarad, a kiadás javításai nem kerülnek be a következő fejlesztési ciklusba.

A kiadási folyamat automatizálása

A rendszeres kiadásokkal rendelkező mobilprojektek esetében a release ág létrehozásának és a verziófrissítésének folyamata automatizálható CI/CD szkripteken keresztül. A GitHub Actions lehetővé teszi egy olyan workflow létrehozását, amely egy gomb megnyomására létrehozza a release ágat automatikus verziófrissítéssel.

A rendszeres kiadásokkal rendelkező mobilprojektek esetében a release ág létrehozásának és a verziófrissítésének folyamata automatizálható CI/CD szkripteken keresztül. A GitHub Actions lehetővé teszi egy olyan workflow létrehozását, amely egy gomb megnyomására létrehozza a release ágat automatikus verziófrissítéssel.

# GitHub Actions — a release ág létrehozásának automatizálása
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 }}