Strategie větvení v Gitu: Git flow vs. trunk-based
Strategie větvení v Gitu určuje, jak se kód dostane z vývoje na produkci. Porovnáme Git flow, GitHub flow a trunk-based vývoj a ukážeme, jak mezi nimi vybrat.
Shrnutí a kontext
Každý tým má strategii větvení. Některé týmy ji mají i sepsanou. Strategie větvení v Gitu určuje, kde vzniká nový kód, jak se dostane na produkci a odkud se vydávají opravy. Níže najdete srovnání Git flow, GitHub flow a trunk-based vývoje a doporučení, jak mezi nimi vybrat.
1. Proč na strategii větvení záleží
Bez dohodnuté strategie často vznikají dlouho žijící větve a při slučování konflikty. Navíc není jasné, co je v které větvi a co z toho běží na produkci. Podpora pak u nahlášené chyby těžko zjišťuje, jestli je oprava už nasazená.
Strategie větvení zároveň určuje, odkud se berou verze a poznámky k vydání. Když je jasné, z které větve a s jakým tagem se vydává, dají se změny mezi dvěma vydáními dohledat bez ručního procházení commitů.
2. Git flow
Git flow popsal Vincent Driessen v roce 2010. Používá dvě trvalé větve: main s vydanými verzemi a develop s rozpracovaným vývojem. Nové funkce vznikají ve větvích feature, vydání se připravuje ve větvi release a opravy produkce ve větvi hotfix.
Model se hodí pro software s plánovanými vydáními a více podporovanými verzemi, třeba pro knihovny nebo aplikace instalované u zákazníků. Sám autor ve své poznámce z roku 2020 doporučuje pro webové aplikace s průběžným nasazováním jednodušší postup.
3. GitHub flow
GitHub flow má jedinou trvalou větev main. Každá změna vznikne v krátké větvi, projde revizí v pull requestu, sloučí se do main a nasadí se.
Hodí se pro webové aplikace a služby, které se nasazují často a mají jednu aktuální verzi. Podmínkou jsou automatické testy, protože main musí být vždy připravená k nasazení.
4. Trunk-based vývoj
Při trunk-based vývoji posílají vývojáři malé změny do hlavní větve (trunku) několikrát denně, přímo nebo přes velmi krátké větve. Rozpracované funkce se skrývají přepínači funkcí (feature flags), tedy nastavením, které funkci zapne až ve chvíli, kdy je hotová.
Vydání se označí tagem přímo na hlavní větvi, případně se pro něj založí krátká větev release. Postup vyžaduje spolehlivé automatické testy a CI/CD, tedy automatické sestavení, testy a nasazení po každé změně.
5. Srovnání strategií větvení
Žádná strategie není správná pro všechny týmy. Rozhoduje, jak často vydáváte a kolik verzí současně podporujete.
| Strategie | Trvalé větve | Jak se vydává | Hodí se pro |
|---|---|---|---|
| Git flow | main, develop | Větev release, tag na main | Plánovaná vydání, více podporovaných verzí, instalace u zákazníků |
| GitHub flow | main | Nasazení po sloučení pull requestu | Webové aplikace s jednou aktuální verzí |
| Trunk-based | main (trunk) | Tag na main nebo krátká větev release | Týmy s automatickými testy a častým nasazováním |
6. Jak strategii větvení vybrat
Při výběru pomůže odpovědět si na několik otázek.
7. Repozitář, pipeline a větve u aplikace
Strategie větvení žije v repozitáři, ale lidé kolem aplikace ji hledají jinde. Konzultant nebo nový kolega potřebuje vědět, kde je repozitář, kde běží pipeline, jaká jsou pravidla větví a kde najde otevřené pull requesty.
V AboutTheApp připojíte k aplikaci odkazy na repozitář na GitHubu, GitLabu nebo v Bitbucketu, na pipeline v GitHub Actions, na nastavení ochrany větví, na seznam pull requestů a na soubor s pravidly větvení. AboutTheApp tyto služby pozná podle adresy a zobrazí u odkazu jejich ikonu. Pokud máte pro některého zákazníka vlastní větev release nebo pipeline pro jeho prostředí, připojíte odkaz jen k jeho instalaci. Verze z tagů může do katalogu verzí zapisovat CI/CD i s poznámkami k vydání.
AboutTheApp drží odkazy na repozitář a pipeline, ale větve, tagy ani pull requesty z Gitu sám nenačítá. Verze a nasazení zapíšete v dashboardu nebo je odešle CI/CD.
Časté otázky
Jaká strategie větvení v Gitu je nejlepší?
Univerzálně nejlepší strategie neexistuje. Pro webové aplikace s častým nasazováním se obvykle hodí GitHub flow nebo trunk-based vývoj. Pro software s plánovanými vydáními a více podporovanými verzemi Git flow.
Používá se Git flow ještě dnes?
Ano, hlavně u knihoven, desktopových a mobilních aplikací a u software instalovaného u zákazníků. Pro webové aplikace s průběžným nasazováním doporučuje i autor Git flow jednodušší postup.
Jaký je rozdíl mezi Git flow a GitHub flow?
Git flow má dvě trvalé větve (main a develop) a samostatné větve pro vydání a opravy. GitHub flow má jen větev main, do které se přes pull request slučují krátké větve a po sloučení se nasazuje.
Co je trunk-based vývoj?
Postup, při kterém vývojáři posílají malé změny do hlavní větve několikrát denně a rozpracované funkce skrývají přepínači funkcí. Vydání se značí tagem na hlavní větvi.
Kde má být strategie větvení popsaná?
V repozitáři, typicky v souboru CONTRIBUTING.md, aby ji vývojáři měli u kódu. Odkaz na ni, na repozitář a na pipeline je dobré mít i u aplikace, například v AboutTheApp, kde je najdou i lidé bez přístupu do repozitáře.
Ve zkratce
Strategie větvení má odpovídat tomu, jak často vydáváte a kolik verzí podporujete. Pokud je sepsaná a odkaz na ni je u aplikace spolu s repozitářem a pipeline, najde ji každý, kdo s aplikací pracuje.
Chcete mít repozitář, pipeline a pravidla u aplikace?
Založte si zdarma aplikaci v AboutTheApp a připojte k ní odkazy na repozitář, pipeline a dokumentaci.