Feature branches vs. trunk-based development v malém týmu
Malý vývojářský tým obvykle nemá luxus dedikovaného release inženýra ani týmu lidí, kteří se starají o buildy a merge konflikty. Každé rozhodnutí o větvení tak přímo ovlivňuje, kolik času vývojáři tráví psaním kódu a kolik bojem s gitem. Feature branches a trunk-based development nejsou jen dvě techniky, ale dva odlišné přístupy k tomu, jak tým přemýšlí o integraci, review a nasazování.
Feature branches staví na izolaci. Každá nová funkce nebo oprava dostane vlastní větev, která se vyvíjí odděleně a do hlavní linie se slévá až ve chvíli, kdy je hotová a otestovaná. Výhodou je klid na práci a možnost dělat code review bez spěchu. Nevýhodou je dlouhý život větve, který přináší bolestivé merge konflikty, a riziko, že se změny v main větvi mezitím posunou tak daleko, že integrace přestane být triviální. Pokud se tým navíc rozrůstá nebo se mění členové, může být obtížné udržet přehled o tom, která větev je aktuální a která už jen čeká na smazání. Právě v takových situacích se vyplatí sáhnout po osvědčených postupech, které popisuje Git workflow pro týmovou spolupráci, a nastavit pravidla dřív, než se z větvení stane chaos.
Trunk-based development jde opačným směrem. Vývojáři commitují přímo do main větve nebo do velmi krátce žijících větví, které se slévají klidně několikrát denně. Předpokladem je silná testovací základna, feature flagy a schopnost rychle reagovat na rozbitý build. Pro malý tým to znamená méně větví, méně merge konfliktů a kratší cestu od nápadu k produkci. Zároveň to vyžaduje disciplínu: každý commit musí být bezpečný, každá změna musí být krytá testy a nikdo nesmí nechat main větev rozbitou přes noc. Pokud tým tuto disciplínu nemá, trunk-based development se rychle promění v neustálý požární poplach.
Volba mezi oběma přístupy závisí na velikosti týmu, zralosti testů a frekvenci nasazování. Malý tým s dobrou CI/CD pipeline a ochotou investovat do automatizace obvykle prosperuje s trunk-based development. Tým, který teprve hledá svůj rytmus, si může nejdřív osvojit krátce žijící feature branches a postupně je zkracovat. Důležité je nebát se pravidla měnit, jakmile přestanou fungovat. Git je nástroj, ne náboženství.