14. Git strategie pro týmy (GitFlow, trunk-based development)

Úvod a kontext

Git sám o sobě nediktuje, jak má tým organizovat své větve — jen dává
nástroje (branch, merge, rebase). Různé týmy proto v čase přijaly
různé konvence, tzv. branching strategie neboli workflow, které
určují, jaké větve existují, jak dlouho žijí a kdy a jak se slučují do
hlavní větve. Volba strategie ovlivňuje rychlost nasazování, riziko
konfliktů a to, jak snadno lze verzovat víc souběžných release verzí.
Tato lekce popisuje dvě nejrozšířenější strategie: GitFlow a
trunk-based development.

Teorie

GitFlow

GitFlow je strategie navržená pro projekty s pravidelnými,
plánovanými releasy (typicky desktopový/mobilní software s verzemi
jako 1.2.0, 1.3.0). Definuje několik typů větví s jasně danou rolí:

• main/master — obsahuje jen produkční kód odpovídající
  vydaným verzím. Každý commit na main odpovídá jednomu release.
• develop — integrační větev, kam se slučují dokončené funkce;
  reprezentuje stav "další verze v přípravě".
• feature/* — krátkodobé větve pro jednotlivé funkce, vytvořené
  z develop a po dokončení do něj zpět sloučené.
• release/* — větev vytvořená z develop, když se blíží
  vydání; slouží k finálnímu ladění, opravám drobných chyb a přípravě
  release poznámek, beze slučování nových funkcí.
• hotfix/* — vytvořená přímo z main pro urgentní opravu v
  produkci, sloučená zpět jak do main, tak do develop.

Výhoda GitFlow je jasná struktura a podpora více souběžně udržovaných
verzí (např. oprava chyby ve verzi 1.x, zatímco se vyvíjí 2.0). Nevýhoda
je vyšší komplexita — víc dlouhotrvajících větví znamená víc příležitostí
pro rozjeté historie a konflikty, a proces je pomalejší pro týmy, které
chtějí nasazovat několikrát denně.

Trunk-based development

Trunk-based development (TBD) je opačný přístup: existuje jediná
dlouhodobá větev (trunk, v Gitu obvykle main), do které všichni
vývojáři integrují své změny často — ideálně alespoň jednou denně.
Feature větve, pokud vůbec existují, žijí jen hodiny až málo dní, ne
týdny. Tento model je základem moderních CI/CD praktik a je typický pro
weby a služby nasazované kontinuálně (SaaS), kde neexistuje pojem
"verze 1.2.0" v tradičním smyslu — nasazuje se prakticky nepřetržitě.

Klíčové techniky, které TBD umožňují bez rizika nasazení nedokončené
funkce:

• Feature flags (feature toggles) — nedokončená funkce se
  zamergne do main skrytá za podmínku (if feature_enabled("nova_funkce")),
  takže kód je v produkci přítomný, ale neaktivní, dokud není hotový a
  otestovaný.
• Malé, časté commity/PR — změny se rozsekají na malé, snadno
  revidovatelné kousky, které lze bezpečně sloučit do main během
  jednoho dne, místo jedné obří větve žijící týdny.
• Silná automatizovaná testovací sada — protože se do main
  integruje často a přímo, spoléhá se na to, že CI pipeline odchytí
  regrese dřív, než se dostanou do produkce.

Kdy použít kterou strategii

• GitFlow se hodí pro software s explicitními, řídce vydávanými
  verzemi, kde je potřeba dlouhodobě udržovat víc verzí paralelně
  (např. desktopová aplikace, embedded firmware, knihovna s LTS
  verzemi).
• Trunk-based development se hodí pro webové aplikace a služby
  nasazované kontinuálně, kde neexistuje potřeba paralelně udržovat
  staré verze a rychlost integrace je prioritou. Většina moderních
  DevOps/cloud-native týmů dnes preferuje TBD právě proto, že lépe
  odpovídá filozofii CI/CD (viz pozdější modul o CI/CD).
• Existují i mezistupně, např. GitHub flow — zjednodušená verze
  bez develop/release větví: jen main a krátkodobé feature
  větve slučované přes pull requesty, bez formálních release větví.
  Je jednodušší než GitFlow, ale méně striktní než čisté TBD.

Praktický příklad

Zjednodušený GitFlow release cyklus:

$ git switch develop
$ git switch -c release/1.4.0
$ # oprava drobných chyb, aktualizace verze v souborech
$ git commit -am "Připravit release 1.4.0"

$ git switch main
$ git merge --no-ff release/1.4.0
$ git tag v1.4.0
$ git push origin main --tags

$ git switch develop
$ git merge --no-ff release/1.4.0
$ git branch -d release/1.4.0

--no-ff (no fast-forward) vynutí vytvoření merge commitu i v
případě, kdy by jinak proběhl fast-forward — u GitFlow je to žádoucí,
aby v historii main byl vidět jasný bod, kde byl release sloučen.

Trunk-based development s feature flagem — nová funkce jde do main
hned, ale zůstává vypnutá, dokud není hotová:

# settings.py
FEATURE_FLAGS = {
    "nove_dashboardy": False,   # zapne se, až bude funkce hotová
}

# views.py
from django.conf import settings

def dashboard_view(request):
    if settings.FEATURE_FLAGS["nove_dashboardy"]:
        return render(request, "dashboard_v2.html")
    return render(request, "dashboard_v1.html")

Kód nové funkce je tak v produkci přítomný a verzovaný spolu s
ostatními od prvního dne vývoje, ale koncoví uživatelé ho nevidí,
dokud se přepínač nezapne — často jen pro interní testery nebo
procento uživatelů (tzv. postupný rollout).

Shrnutí

GitFlow strukturuje vývoj kolem dlouhotrvajících větví (develop,
release/*, hotfix/*) a je vhodný pro software s explicitními,
řídce vydávanými verzemi vyžadující paralelní údržbu víc verzí.
Trunk-based development naopak integruje změny do jediné hlavní větve
často a v malých krocích, typicky s podporou feature flagů, a je
přirozeným základem pro kontinuální nasazování moderních webových
služeb. Volba strategie by měla odpovídat způsobu, jakým se software
skutečně vydává a provozuje, ne být zvolena jen podle popularity.

Kontrolní otázky

1. Jaké typy větví definuje GitFlow a k čemu slouží release/* větev?
2. Proč je trunk-based development přirozeně blíž filozofii CI/CD než
   GitFlow?
3. Co je feature flag a jak umožňuje bezpečně mergovat nedokončenou
   funkci do hlavní větve?
4. Váš tým vyvíjí veřejný web nasazovaný několikrát denně a nepotřebuje
   udržovat starší verze paralelně. Kterou strategii byste doporučili
   a proč?