Git workflow: jak používají Git jednotlivci, týmy i velké firmy

Znát příkazy Gitu je jedna věc. Druhá věc je domluvit se, jak ho budete používat: kdy zakládat větve, kdo schvaluje změny a kdy se nasazuje. Tomu se říká Git workflow a v tomto článku ukážu, jak se liší u jednotlivce, malého týmu, korporátu a open source projektu.

Pokud s Gitem začínáte, přečtěte si nejdřív první díl série: Co je Git a jak funguje.

Git workflow jednotlivce: jednoduše, ale s větvemi

Když pracujete sám, stačí minimum pravidel. I tak se ale vyplatí jedna zásada: větev main udržujte vždy funkční a nasaditelnou. Na větší změny si vytvořte feature větev:

git switch -c feature/novy-kosik
# ... práce ...
git switch main
git merge feature/novy-kosik

Praktický přínos: když klient zavolá s urgentní opravou, přepnete na čistý main, opravíte, nasadíte a vrátíte se k rozdělané práci. Žádné "nemůžu nasadit, mám to rozbité".

GitHub Flow: standard malých týmů

Týmy do zhruba deseti lidí nejčastěji používají GitHub Flow. Je jednoduchý a pokrývá 90 % potřeb agentur, startupů i menších firem:

1. main je vždy nasaditelný
2. Každá změna vzniká v nové větvi (feature/platebni-brana, fix/cookie-lista)
3. Po dokončení se otevře pull request
4. Kolega udělá code review, automaticky proběhnou testy
5. Po schválení se větev mergne do main a nasadí

Co je pull request

Pull request (PR) není příkaz Gitu, ale funkce GitHubu (GitLab mu říká merge request). Je to žádost o sloučení větve spojená s diskuzí: vidíte kompletní rozdíl změn, kolegové komentují konkrétní řádky a automatika spouští testy. Teprve po schválení se kód dostane do main. PR je dnes srdce týmové spolupráce nad kódem.

Git Flow: klasika pro verzovaný software

Větší projekty, které udržují více verzí současně, používají robustnější model Git Flow s několika trvalými větvemi:

• main: pouze produkční, otagované verze
• develop: integrační větev, kde se schází hotová práce
• feature/*: vývojové větve, vychází z develop
• release/*: příprava a stabilizace verze
• hotfix/*: urgentní opravy produkce přímo z main

Git Flow dává smysl třeba u softwaru, který si zákazníci instalují: verze 1.x musí dostávat opravy, i když už existuje verze 2.x. Pro běžný web nebo SaaS je dnes považovaný za zbytečně těžkopádný.

Trunk-based development: jak to dělají Google a Meta

Největší technologické firmy jdou opačným směrem. V trunk-based developmentu existuje jediná hlavní větev a pravidla zní:

• Větve žijí maximálně den nebo dva, pak se mergují
• Nedokončené funkce se schovávají za feature flagy (přepínače v kódu)
• Každý commit prochází tisíci automatických testů (CI)
• Nasazuje se průběžně, klidně mnohokrát denně

Tenhle model stojí a padá s masivní automatizací. Bez kvalitních testů ho zavádět nelze.

Co mají velké firmy navíc

Bez ohledu na zvolený model přidávají korporáty další vrstvy ochrany:

• Protected branches: do main nelze pushovat přímo, jen přes schválený PR
• Povinné code review: často dvě a více schválení
• CODEOWNERS: soubor určující, kdo musí schválit změny v které části kódu
• CI/CD pipeline: automatické testy, statická analýza, security skeny a nasazení

Open source workflow: fork a pull request

U cizích projektů na GitHubu (knihovny, WordPress pluginy, frameworky) nemáte práva zápisu. Proto existuje fork: kopie repozitáře pod vaším účtem.

1. Na GitHubu kliknete na Fork
2. Naklonujete si svůj fork a vytvoříte větev se změnou
3. Pushnete do svého forku
4. Otevřete pull request z forku do původního repozitáře
5. Maintainer (správce projektu) udělá review a rozhodne o sloučení

git clone git@github.com:vas-ucet/projekt.git
git remote add upstream git@github.com:autor/projekt.git
git switch -c fix/preklep-v-dokumentaci
# ... změna, commit, push do forku, PR na GitHubu ...

Právě takhle vznikají příspěvky do Symfony, WordPressu a tisíců knihoven, které denně instalujeme přes Composer nebo npm. O tom, jak tyto knihovny vydávají verze, píšu ve třetím díle: Git tagy a sémantické verzování.

Který workflow si vybrat?

Nejčastější otázky

Merge, nebo rebase?

Merge zachová historii včetně merge commitů, rebase ji přepíše do čisté přímky. Obojí je správně, tým si jen musí zvolit konvenci. Zlaté pravidlo: nikdy nerebasujte větev, kterou už používá někdo jiný.

Jak pojmenovávat větve?

Popisně a s prefixem podle typu: feature/platebni-brana, fix/spatne-dph, hotfix/padajici-objednavka. Tým pak na první pohled ví, co větev obsahuje.

Musím používat pull requesty, když jsme dva?

Nemusíte, ale vyplatí se to. Code review odhalí chyby a oba máte přehled o celém kódu. Navíc si zvyknete na proces, který je všude standardem.

Shrnutí

Neexistuje jediný správný Git workflow, jen workflow přiměřený velikosti týmu a typu projektu. Jednotlivci stačí disciplína s větvemi, malému týmu GitHub Flow a velké firmy sahají po trunk-based developmentu s masivní automatizací. V posledním díle série se podíváme na to, jak profesionálně verzovat pomocí tagů a SemVeru.

Potřebujete pomoct s webem, nasazováním nebo vývojovým procesem? Napište mi.