Git Flow: co to je, model větvení a použití v projektech

Co je Git Flow?

Git Flow — je model větvení Git, který stanovuje přísnou strukturu větví a pravidel slučování pro řízení vývoje, release a oprav. Vincent Driessen publikoval článek „A successful Git branching model“ v lednu 2010 a od té doby se Git Flow stal de facto standardem v podnikovém vývoji Java a .NET. Hlavní myšlenka — rozdělení kódu do pěti typů větví s různou úrovní stability.

Podle Atlassian Git Tutorials, 2024, Git Flow je založen na dvou trvalých větvích: main (dříve master) a develop. Všechny ostatní větve jsou dočasné: feature, release, hotfix. Každý typ větve má jasně definovaný životní cyklus a pravidla slučování. V mobilním vývoji se Git Flow používá v projektech s pravidelnými release cykly (2–4 týdny) a podporou více verzí.

Git Flow se liší od jednoduchých modelů (GitHub Flow) tím, že vyžaduje samostatnou větev develop pro integraci. To přidává jeden krok do procesu slučování, ale poskytuje dodatečnou izolaci nedokončených funkcí od kódu připraveného k release.

Vincent Driessen a historie Git Flow

V roce 2010 Vincent Driessen publikoval příspěvek „A successful Git branching model“, který se stal jedním z nejcitovanějších v historii Git. Model byl vytvořen pro projekt s pevnými release a paralelní podporou verzí. V roce 2020 Driessen přiznal, že Git Flow je zastaralý pro moderní CI/CD postupy, ale model zůstává relevantní pro projekty s dlouhým release cyklem a potřebou podpory starých verzí.

# Inicializace Git Flow
git flow init

# Vytvoření feature větve
git flow feature start "add-auth"

# Dokončení feature větve (sloučení do develop)
git flow feature finish "add-auth"

# Vytvoření release
git flow release start "1.2.0"
git flow release finish "1.2.0"

Větev Main: release kód a tagování

Main (dříve master) — hlavní větev obsahující pouze release kód připravený k nasazení. Každý commit v main musí odpovídat konkrétní verzi produktu označené tagem ve formátu sémantického verzování, například v1.0.0, v1.1.0. Žádný přímý vývoj v main se neprovádí — změny se sem dostávají pouze přes release nebo hotfix větve.

Podle semver.org, 2024, tagy v main používají formát MAJOR.MINOR.PATCH. MAJOR se zvyšuje při nekompatibilních změnách API, MINOR — při přidávání funkcionality se zpětnou kompatibilitou, PATCH — při opravách chyb. V Git Flow každý finish release automaticky vytvoří commit v main s tagem verze.

Main — jediná větev, která se nasazuje do produkce. Pro mobilní projekty to znamená, že při push do main se spustí pipeline sestavení App Bundle nebo IPA a publikování do Google Play / App Store. V nastavení CI/CD GitLab je main chráněna proti force-push a smazání.

Sémantické verzování a tagy

Každý commit v main je doprovázen tagem ve formátu SemVer: vMAJOR.MINOR.PATCH. MAJOR — pro nekompatibilní změny API, MINOR — pro novou funkcionalitu se zpětnou kompatibilitou, PATCH — pro opravy chyb. Příklad: v2.1.0 znamená druhou hlavní release s novými funkcemi a bez oprav chyb. V Git Flow se tagy vytvářejí automaticky při finish release nebo hotfix pomocí příkazu git flow release finish.

Větev Develop: integrační linie vývoje

Develop — druhá trvalá větev Git Flow, určená pro integraci všech dokončených funkcí. Vývojáři slévají feature větve do develop po absolvování code review a CI/CD kontrol. Develop obsahuje nejnovější stabilní verzi kódu zahrnující všechny implementované funkce aktuálního sprintu.

Podle DataSift Git Flow Guide, 2024, develop může být dočasně nestabilní kvůli nedokončeným integracím. Pro prevenci problémů týmy praktikují Continuous Integration (CI): každá funkce před sloučením do develop projde kompletní sadou testů. Pokud CI selže — vývojář opraví kód do dalšího sloučení. Develop je vždy vázána na aktuální verzi main: ihned po release je develop synchronizována s main pomocí sloučení.

Feature větve: vývoj nové funkcionality

Feature větve — dočasné větve pro vývoj jednotlivých funkcí, oprav chyb nebo experimentů. Každá feature větev se vytváří z develop a po dokončení se slévá zpět do develop. Název feature větve obvykle obsahuje číslo úkolu nebo krátký popis: feature/APP-123-add-oauth, feature/redesign-profile. V Git Flow mohou feature větve existovat neomezeně dlouho.

Podle Pro Git Book, 2024, feature větve jsou izolované vývojové prostředí: změny v jedné větvi neovlivňují ostatní až do okamžiku sloučení. V mobilních projektech se feature větve synchronizují s develop pomocí rebase nebo merge, aby se předešlo velkým konfliktům při dokončení. Doporučuje se rebase feature větve na develop před vytvořením MR.

# Ruční vytvoření feature větve (bez git flow)
git checkout -b feature/APP-142-add-auth develop
git commit -m "Add OAuth2 authentication with Google"
git push origin feature/APP-142-add-auth

# Vytvoření MR v GitLab přes CLI
glab mr create \
    --source-branch "feature/APP-142-add-auth" \
    --target-branch "develop" \
    --title "Add OAuth2 authentication"

Release větve: příprava release

Release větve — dočasné větve vytvořené z develop pro přípravu release. Když develop obsahuje dostatečnou sadu funkcí pro novou verzi, tým vytvoří větev release/X.Y.Z (například release/2.1.0). V této větvi se provádějí pouze konečné úpravy: zvýšení verze, aktualizace lokalizace, konečné testování, oprava kritických chyb.

Podle Atlassian Git Tutorials, 2024, release větev řeší klíčový problém: izolaci konečných úprav od paralelního vývoje. Zatímco se release připravuje k vydání, v develop se nadále slévají nové funkce pro příští release. Po dokončení se release větev slévá do main (s tagem) a do develop (pro synchronizaci zvýšení verze).

Hotfix větve: naléhavé opravy v produkci

Hotfix větve — dočasné větve pro naléhavé opravy kritických chyb v produkci. Jediný typ větve Git Flow, který se vytváří z main, nikoli z develop. Formát názvu: hotfix/X.Y.Z+1 (například hotfix/2.1.1). Po dokončení se hotfix větev slévá současně do main (jako nová opravná release) a do develop (aby oprava nebyla ztracena při příštích release).

Podle DataSift Git Flow Guide, 2024, hotfix větve by měly být co nejkratší — pouze oprava a test. Hotfix by neměl zahrnovat nové funkce nebo refactoring. V mobilním vývoji se hotfix používá pro opravu kritických pádů (crash rate > 0.1%), bezpečnostních zranitelností nebo blokujících chyb v App Store.

Výhody a nevýhody Git Flow pro mobilní vývoj

Git Flow poskytuje jasnou strukturu, která je zvláště užitečná pro velké týmy a projekty s pravidelnými release. Výhody: izolace nedokončených funkcí ve feature větvích, možnost přípravy release bez blokování vývoje, podpora více verzí prostřednictvím hotfix. Nevýhody: složitost pro začátečníky, potřeba pravidelného rebase feature větví, konflikty u dlouho žijících větví.

Podle Martin Fowler, 2024, hlavní nevýhoda Git Flow — dlouho žijící feature větve. Pokud se funkce vyvíjí 2+ týdny bez synchronizace s develop, konflikt při sloučení se stává významným. Pro mobilní projekty se doporučuje denní synchronizace feature větve pomocí rebase na develop.

Git Flow není doporučován pro projekty s Continuous Deployment (každý commit do main → do produkce). Pro takové projekty GitHub Flow nebo Trunk-Based Development poskytují jednodušší a rychlejší model. Ale pro projekty s release cykly a podporou starých verzí zůstává Git Flow optimální volbou.

Kdy je Git Flow pro tým škodlivý

Git Flow se stává problémem ve třech případech: tým menší než 5 lidí (nadměrná složitost), Continuous Deployment (zpoždění dodávky), nedostatek rebase disciplíny (dlouho žijící feature větve vytvářejí merge konflikty). Pokud tým tráví více než 20% času slučováním větví a řešením konfliktů — Git Flow není pro tento tým vhodný, ani při velké velikosti.

Alternativy Git Flow: GitHub Flow a Trunk-Based Development

Alternativy Git Flow nabízejí jednodušší proces pro týmy praktikující CI/CD. GitHub Flow používá pouze jednu trvalou větev (main) a feature větve. Každá funkce se vytváří z main, po revizi a CI se slévá zpět do main a okamžitě se nasazuje. GitHub Flow je jednodušší, ale nepodporuje izolaci nedokončených funkcí a paralelní přípravu release.

Podle GitHub Docs, 2024, Trunk-Based Development (TBD) jde ještě dále: všichni vývojáři pracují v jedné větvi (trunk) s krátkožijícími feature větvemi na 1–2 dny. Feature toggles (přepínače funkcí) řídí viditelnost nedokončeného kódu. TBD vyžaduje vysokou CI/CD disciplínu a automatizaci testování.

• GitHub Flow — jeden main + feature větve, ideální pro CI/CD a malé týmy
• GitLab Flow — rozvíjí Git Flow s environmentálními větvemi (staging, production)
• Trunk-Based Development — jedna větev + feature toggles, maximum CI/CD, minimum slučování
• One Flow — zjednodušený Git Flow bez develop větve, pouze main + feature + release