3.4 Větve v systému Git - Postupy při práci s větvemi

Protože Git používá jednoduché třícestné slučování, je opakované začleňování jedné větve do druhé velmi snadné i v průběhu delšího času. To znamená, že můžete mít neustále otevřeno několik větví a můžete je používat pro různé fáze vývojového cyklu. Některé z nich můžete pravidelně slučovat s jinými.

Řada vývojářů, kteří Git používají, si tento přístup osvojila, takže například ve větvi master uchovávají kód, který je zcela stabilní — kód, který byl nebo bude součástí zveřejněné verze. Kromě toho mají další, paralelní větev develop nebo next, ve které pracují nebo ji používají pro testování stability. Tato větev nemusí být nutně stabilní, ale jakmile se dostane do stabilního stavu, může být začleněna do větve master. Do ní se vtahují tématické větve (ty dočasné, jako byla dřívější větev iss53) jakmile jsou připravené — abychom zajistili, že projdou všemi testy a nezavlečou chyby.

Ve skutečnosti hovoříme o ukazatelích pohybujících se vzhůru po linii revizí, které zapisujete. Stabilní větve leží v linii historie revizí níže a větve s nejčerstvějšími novinkami se nacházejí nad nimi.

Většinou je jednodušší uvažovat o větvích jako o pracovních zásobnících, kdy sada revizí postupuje do stabilnějšího zásobníku až po úplném otestování.

Takto můžete pokračovat pro několik úrovní stability. Některé větší projekty mají také větev proposed nebo pu (proposed updates, návrh úprav), která přebírá věci z větví, které nejsou způsobilé k začlenění do větví next nebo master. Hlavní myšlenka je taková, že se větve nacházejí na různé úrovni stability. Jakmile dosáhnou stability o stupeň vyšší, jsou začleněny do větve nad nimi. Zopakujme, že není nutné používat několik dlouhotrvajících větví, ale často to může být užitečné, zejména pokud se jedná o velmi velké nebo složité projekty.

Naproti tomu tématické větve se hodí v projektech jakékoli velikosti. Tématická větev (topic branch) je krátkodobá větev, kterou vytvoříte a používáte pro jediný konkrétní účel nebo práci. Je to něco, co byste v dřívějších systémech pro správu verzí nikdy nedělali, protože v nich je vytváření a slučování větví většinou náročné. Ale v Gitu je běžné, že se větev vytvoří, pracuje se v ní, sloučí se a odstraní — to vše i několikrát za den.

Viděli jste to v předchozí části, kdy jste si vytvořili větve iss53 a hotfix. Zapsali jste do nich pár revizí a smazali jste je hned po začlenění změn do hlavní větve. Tato technika umožňuje rychlé a snadné přepínání kontextu. A protože je vaše práce rozdělena do zásobníků, kde všechny změny v jedné větvi souvisejí s jedním tématem, je při kontrole kódu snazší dohledat, čeho se změny týkaly a podobné věci. Změny v nich můžete uchovávat několik minut, dní i měsíců a začlenit je až ve vhodnou chvíli — nezávisle na pořadí, v jakém vznikly nebo byly vyvíjeny.

Uvažujme příklad, kdy něco vytvoříte (v master), odvětvíte se kvůli řešení problému (iss91), chvíli na něm pracujete, vytvoříte druhou větev, abyste zkusili jiné řešení stejného problému (iss91v2). Vrátíte se zpět do větve master, kde chvíli pokračujete v práci a vytvoříte další větev, ve které chcete vyzkoušet něco, co by nemusel být dobrý nápad (větev dumbidea). Historie revizí bude vypadat nějak takto:

Řekněme, že se nyní rozhodnete, že se vám druhé řešení problému líbí víc (iss91v2). Svůj nápad ve větvi dumbidea jste ukázali kolegům a ti ho považují za geniální. Původní větev iss91 můžete zahodit (s ní i revize C5 a C6) a začlenit zbylé dvě větve. Vaše historie pak vypadá následovně:

Další detaily různých možných pracovních postupů, které můžete pro váš projekt v Gitu využít, rozebereme v kapitole Distribuovaný Git. Takže než se rozhodnete, jaké schéma větvení bude váš příští projekt využívat, přečtěte si ji.

Při tom všem, co nyní děláte, je důležité mít na paměti, že všechny tyto větve jsou zcela lokální. Veškeré větvení a slučování se odehrává pouze ve vašem gitovém repozitáři — neprobíhá žádná komunikace se serverem.