Git Flow — feature, release a hotfix větve

Co tato dovednost pokrývá

Větvící model Gitflow — dvě dlouhověké větve (main, develop) plus tři druhy krátkověkých podpůrných větví (feature/*, release/*, hotfix/*) — a příkazy k obsluze každé z nich. Upřímně pokrývá i to, kdy je Gitflow špatná volba. Pro běžné příkazy gitu viz Git , pro souběžné větve v oddělených adresářích viz Git Worktrees .

Kdy ji použít

• Při rozhodování, odkud má změna větvit a kam se má slučovat zpět v Gitflow
• Při zahájení feature, přípravě release nebo nasazení urgentního hotfixu
• Při zavádění release-orientovaného větvícího modelu pro verzovaný produkt
• Při rozhodování, zda týmu vyhovuje Gitflow, nebo jednodušší model (trunk-based, GitHub Flow)

Větve

• main — produkce. Každý commit je vydaná, otagovaná verze.
• develop — integrační větev. Dokončené features sem přistávají první.
• feature/* — jedna na jednotku práce; větví z develop a slučuje se zpět do develop.
• release/* — větví z develop pro stabilizaci verze; slučuje se do main i develop.
• hotfix/* — větví z main pro opravu produkce; slučuje se do main i develop.

Gitflow lze řídit čistým git (níže, funguje všude) nebo rozšířením příkazové řádky git flow, které stejné kroky obaluje.

Kdy Gitflow NEpoužívat

Stojí za to být upřímný — Gitflow je pro moderní webovou práci často špatná výchozí volba.

• Kontinuálně nasazované webové aplikace / SaaS: preferujte trunk-based development nebo GitHub Flow — krátkověké větve z main, sloučit a nasadit. Dlouhověké develop a release větve Gitflow přidávají ceremonii, kterou pipeline nasazující při merge nepotřebuje.
• Malé týmy / sólo projekty: režie se málokdy vyplatí.
• Pokud nasazujete main mnohokrát denně, rozdělení develop/release jde proti vám.

Gitflow se vyplatí, když vydáváte oddělené, verzované release (instalovaný software, mobilní aplikace, knihovny, on-prem produkty) a možná musíte podporovat více verzí najednou.

Nastavení

# Čistý git: jednorázově vytvořit větev develop z main
git switch main
git switch -c develop
git push -u origin develop

# Nebo rozšířením git flow (interaktivní; přijměte výchozí hodnoty)
git flow init

Feature větve

Větví z develop, slučují se zpět do develop. Nikdy nevětvete feature z main.

# Start
git switch develop
git pull
git switch -c feature/short-description

# ... commity práce ...

# Finish — začlenění zpět do develop
git switch develop
git pull
git merge --no-ff feature/short-description
git push
git branch -d feature/short-description

# ekvivalent git flow
git flow feature start short-description
git flow feature finish short-description

--no-ff udrží commity feature seskupené pod merge commitem, takže tvar větve zůstane v historii viditelný.

Release větve

Větví z develop, jakmile je rozsah release zmražen. Sem patří jen stabilizační commity (bump verze, changelog, opravy chyb) — žádné nové features. Slučte do main i develop a otagujte main.

# Start
git switch develop
git pull
git switch -c release/1.4.0
# ... bump verze, aktualizace changelogu, oprava blokujících chyb ...

# Finish
git switch main
git merge --no-ff release/1.4.0
git tag -a v1.4.0 -m "Release 1.4.0"

git switch develop
git merge --no-ff release/1.4.0   # aby se opravy z release větve vrátily do develop

git push origin main develop --tags
git branch -d release/1.4.0

# ekvivalent git flow
git flow release start 1.4.0
git flow release finish 1.4.0     # sloučí do main + develop a otaguje

Sloučení release zpět do develop je krok, na který se zapomíná — vynechte ho a opravy chyb z release větve zmizí z probíhajícího vývoje.

Hotfix větve

Pro urgentní opravu produkce. Větev z main, sloučit do main i develop, otagovat main novou patch verzí.

# Start z produkce
git switch main
git pull
git switch -c hotfix/1.4.1
# ... oprava chyby ...

# Finish
git switch main
git merge --no-ff hotfix/1.4.1
git tag -a v1.4.1 -m "Hotfix 1.4.1"

git switch develop
git merge --no-ff hotfix/1.4.1

git push origin main develop --tags
git branch -d hotfix/1.4.1

# ekvivalent git flow
git flow hotfix start 1.4.1
git flow hotfix finish 1.4.1

Pokud je při hotfixu otevřená release/* větev, slučte hotfix do release větve místo do develop (release větev ho při finish přenese do develop) — jinak slučujete stejnou opravu dvakrát.

Přehled větví

Bezpečnostní pravidla

• main je vždy vydatelný. Slučujte do něj jen release/* nebo hotfix/*, vždy otagované.
• Žádné features na release/* nebo hotfix/* — jen stabilizační/opravné commity.
• Vždy slučte release a hotfix větve zpět do develop, jinak se opravy z probíhající práce ztratí.
• Používejte --no-ff pro sloučení podpůrných větví, aby historie ukazovala, kde se každá větev začlenila.
• Otagujte každé sloučení do main sémantickou verzí — tag je identitou vydaného artefaktu.

Časté chyby

• Feature větev žije týdny. Čím déle se vzdaluje od develop, tím horší je závěrečný merge. Průběžně do ní slučujte develop a práci dělte na menší features.
• Nové features do release větve. Release větev má verzi stabilizovat; každá přidaná funkce stabilizaci vrací na začátek.
• Hotfix přímo na main. Bez větve hotfix/* se oprava snadno nedostane do develop a v příští verzi se chyba vrátí.
• Chybějící tag. Sloučení do main bez tagu znamená, že nejde dohledat, který commit je která verze.
• Fast-forward merge podpůrných větví. Bez --no-ff zmizí z historie hranice feature a nejde ji revertovat jedním commitem.
• Gitflow „protože se to tak dělá“. U webu nasazovaného při každém merge je develop jen další větev, kterou je potřeba udržovat v synchronizaci.

Řešení problémů