Release Branch v Git — co to je, účel a proces práce

Co je Release Branch v Git

Release Branch (větev vydání) — je dočasná větev v Git Flow, vytvořená z develop, když se tým rozhodne, že aktuální sada funkcí je připravena k vydání. Existuje přesně tak dlouho, jak trvá konečná příprava vydání — od několika hodin do několika dnů.

Hlavním účelem release větve je zmrazit konkrétní sadu funkcí pro vydání, aniž by se zastavil vývoj následujících verzí. Zatímco se release větev připravuje k vydání, ostatní vývojáři mohou pokračovat ve slučování feature větví do develop pro další vydání.

V release větvi se nevytvářejí nové funkce — pouze opravy chyb, aktualizace verze aplikace, lokalizace a dokumentace. Po dokončení všech prací se release větev sloučí do main (označí se jako vydání) a zpět do develop (aby se opravy chyb dostaly do budoucích verzí).

Podle Atlassian, 2024, jsou release větve kriticky důležité pro projekty s pravidelnými cykly vydání — zajišťují předvídatelnost a stabilitu procesu vydávání.

Životní cyklus release větve

Životní cyklus release větve od vytvoření po odstranění zahrnuje několik fází. Pochopení každé fáze pomáhá týmu synchronizovat akce a vyhnout se chybám.

1. Vytvoření — z posledního commitu develop se vytvoří větev s názvem release/2.5.0. develop nadále přijímá feature větve pro další verzi.
2. Příprava — v release větvi se aktualizuje verze aplikace v build.gradle, Info.plist a dalších konfiguračních souborech.
3. Oprava chyb — opravují se kritické chyby nalezené během konečného testování. Pouze chyby — žádné nové funkce.
4. Konečné testování — QA tým provádí regresní testování na release větvi. Nové chyby jsou odeslány k opravě do stejné větve.
5. Sloučení do main — release větev se sloučí do main s příznakem --no-ff. Vytvoří se tag vydání: v2.5.0.
6. Sloučení do develop — release větev se sloučí zpět do develop, aby se opravy chyb z vydání dostaly do aktuálního vývoje.
7. Odstranění — release větev se odstraní lokálně i vzdáleně, protože její úkol je splněn.

Bod 6 — zpětné sloučení do develop — se často zapomíná, ale je kriticky důležitý. Bez něj se opravy chyb provedené v release nedostanou do develop a v příštím vydání se stejné chyby mohou objevit znovu.

Typické délky fází release větve

Délka života release větve závisí na složitosti vydání a kvalitě kódu v develop. V průměru příprava trvá 2 až 5 pracovních dnů pro mobilní aplikaci střední velikosti.

Co se dělá v release větvi

V release větvi se provádí přísně omezená sada úkolů. Jakákoli odchylka od tohoto seznamu porušuje model Git Flow a vytváří rizika pro stabilitu vydání.

Pravidlo zákazu nových funkcí — nejdůležitější v release větvi. Pokud funkce nestihla vydání, čeká na další cyklus. Pokus o protlačení nedokončené funkce do release větve — hlavní příčina zpoždění termínů a chyb v produkci.

Aktualizace verze v mobilním projektu

V release větvi se povinně aktualizuje číslo verze aplikace. Pro Android jsou to pole versionCode a versionName v build.gradle, pro iOS — CFBundleShortVersionString v Info.plist.

// build.gradle (app-level) — aktualizace verze v release větvi
android {
    defaultConfig {
        versionCode 42
        versionName "2.5.0"
    }
}

// Pro iOS — aktualizace Info.plist
// CFBundleShortVersionString = 2.5.0
// CFBundleVersion = 42

Rozdíly mezi release a hotfix

Začínající vývojáři často zaměňují release a hotfix větve, ačkoli jejich účel je zásadně odlišný. Chyba při výběru typu větve může vést ke zpoždění kritické opravy nebo narušení procesu vydání.

• Zdroj — release se vytváří z develop, hotfix — z main. To je hlavní rozdíl, který určuje vše ostatní.
• Naléhavost — release je plánovaný: tým sám rozhoduje, kdy zahájit přípravu. Hotfix je naléhavý: problém v produkci vyžaduje okamžitou opravu.
• Obsah — release může zahrnovat několik oprav a aktualizaci verze. Hotfix obsahuje pouze jednu kritickou opravu.
• Sloučení — release se slučuje do main a develop. Hotfix se také slučuje do main a develop, ale prioritně.
• Délka života — release žije 1 až 7 dní. Hotfix žije 30 minut až 1 den.

Pokud je chyba objevena během přípravy vydání (v release větvi) — jedná se o běžnou opravu chyby. Pokud je chyba objevena v produkci (na main) — jedná se o hotfix a vytváří se z main, i když release větev již existuje.

Pravidla pojmenování release větví

Jednotný standard pojmenování release větví zjednodušuje navigaci v repozitáři a umožňuje CI/CD systémům automaticky určit, že větev patří do procesu vydání.

• release/X.Y.Z — standardní formát Git Flow, kde X.Y.Z je verze vydání. Příklad: release/2.5.0.
• release/název — alternativní formát s kódovým názvem vydání. Příklad: release/merlin.
• release/datum — formát s datem vydání. Používá se zřídka, protože verze je důležitější než datum. Příklad: release/2024-12-01.

Formát release/X.Y.Z — preferovaný, protože explicitně spojuje větev s číslem verze, které bude přiděleno vydání. To zjednodušuje vyhledávání a automatické zpracování skripty CI/CD.

Strategie zpětného sloučení do develop

Zpětné sloučení (merge back) release větve do develop — jedna z nejdůležitějších a současně často přehlížených operací. Bez něj všechny opravy chyb provedené v release zůstanou pouze ve verzi vydání a nedostanou se do dalšího cyklu vydání.

Proces zpětného sloučení se provádí poté, co byla release větev již sloučena do main. Nejprve se release sloučí do develop, poté — odstraní. To zaručuje, že develop obsahuje všechny opravy provedené během přípravy vydání.

Po zpětném sloučení jsou možné konflikty — zejména pokud se v develop již objevily nové feature větve, které měnily stejné soubory. Vývojář odpovědný za vydání tyto konflikty řeší a pushuje develop na server.

Některé týmy používají rebase místo merge pro zpětné sloučení, aby historie zůstala lineární. Merge je však pro develop bezpečnější, protože nepřepisuje historii commitů, které již mohly být použity jinými vývojáři.

Příklady příkazů pro práci s release

Podívejme se na celý cyklus práce s release větví: od vytvoření po odstranění po úspěšném vydání mobilní aplikace verze 2.5.0.

# 1. Vytvoření release větve z develop
git checkout develop
git pull origin develop
git checkout -b release/2.5.0

# 2. Aktualizace verze a opravy chyb
git add build.gradle
git commit -m "Bump version to 2.5.0"

# 3. Oprava chyb (pouze bugfixes)
git add src/fix/
git commit -m "Fix crash on payment screen"

# 4. Odeslání release větve na server
git push origin release/2.5.0

# 5. Sloučení release do 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. Zpětné sloučení do develop
git checkout develop
git merge --no-ff release/2.5.0
git push origin develop

# 7. Odstranění release větve
git branch -d release/2.5.0
git push origin --delete release/2.5.0

Příkazy 5 a 6 — dvojité sloučení — jsou kriticky důležité. Nejprve main obdrží kód vydání a tag, poté se develop synchronizuje s opravami chyb z release. Pokud se krok 6 přeskočí, opravy z vydání se nedostanou do dalšího cyklu vývoje.

Automatizace procesu vydání

Pro mobilní projekty s pravidelnými vydáními lze proces vytvoření release větve a aktualizace verze automatizovat pomocí CI/CD skriptů. GitHub Actions umožňuje vytvořit workflow, které po stisknutí tlačítka vytvoří release větev s automatickou aktualizací verze.

Pro mobilní projekty s pravidelnými vydáními lze proces vytvoření release větve a aktualizace verze automatizovat pomocí CI/CD skriptů. GitHub Actions umožňuje vytvořit workflow, které po stisknutí tlačítka vytvoří release větev s automatickou aktualizací verze.

# GitHub Actions — automatizace vytvoření release větve
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 }}