Lekce 5 - Git - Rozděluj a panuj

V minulém dílu našeho seriálu o GITu jsme se věnovali prohlížení historie. To by nám nebylo příliš přínosné, kdybychom nevěděli, co máme kde hledat. Stejně jako obvykle, i v souborech musí být pořádek. Git nám neumožňuje vytváření složek, do kterých bychom si soubory „uklidili“. Přináší něco lepšího – větve. Dnes se podíváme, jak se s větvemi pracuje a co nám do vývoje přinášejí.

Co je to větev

Když jsme ve 3. díle probírali commity, zmiňoval jsem rodiče commitu. Díky rodičům můžeme zapsat větev. Bude to sekvence commitů, které na sebe navazují. Commit, který má dva předky, se nazývá merge. Zde mohou větve zanikat, ale není to pravidlem, záleží na situaci. Větve bude tedy sekvence commitů, jdoucích po sobě. Pomocí názvu větve se můžeme přesunout na poslední commit ve větvi. Název větve tedy funguje jako odkaz.

Vytvoření větve

Větev můžeme vytvořit z libovolného commitu. Jak se přesouvat mezi commity jsme si již říkali, jedná se o příkaz git checkout. Novou větev vytvoříme přes příkaz git branch <NazevVetve>. Tato větev bude navazovat na commit, ve kterém právě jste. Lze tedy vytvářet i větve z již existujících commitů.

Co nám větve přinášejí?

Pomocí větví můžeme projekt rozdělit do několika paralelních sekvencí, kde každá funguje samostatně. To nám přináší spoustu výhod. Hlavní výhoda je možnost rozdělit práci do několika týmů, aniž by se ovlivňovaly. Když jeden tým napíše špatný kód, který poté nepůjde zkompilovat, ostatním týmům to nevadí. Zároveň, pokud zjistíme, že jsme šli špatným směrem (například špatný návrh programu), není nic snazšího než vytvořit novou větev ze stejného místa a část kódu přepsat. Tak se nemusíme zabývat tím, co už bylo napsáno a hledat, co jsme již opravili a co ještě ne. Tak říkajíc, budeme mít zas čistý stůl. Špatnou větev je poté snadné smazat. Větve také můžeme použít jako takovou myšlenkovou mapu.

Nápad na novou funkci v systému? No, tak si vytvoříme novou větev a implementujeme ji v této větvi. A když ji chceme přidat až do další verze? Žádný problém, prostě si větve spojíme, jak budeme sami potřebovat. Onen nápad vlastně vůbec nebyl potřeba? Nemusíme jej zmergovat a do vývoje se tedy vůbec nedostane. A když později zjistíme, že bychom jej skutečně chtěli zahrnout do systému? Jediné zmergování a máme jej tam.

Jaký je poté výsledek? Není nic snadnějšího, než si ukázat nějaký fiktivní projekt.

Tento výukový obsah pomáhají rozvíjet následující firmy, které dost možná hledají právě tebe!

Vidíme několik paralelních linií. Z pravé strany je to master, která je veřejná a představuje samotný zveřejněný program. K této větvi se dostaneme nejčastěji. Je to větev, která se klonuje z repositáře. Vedle ní je linie hotfixes – tedy důležité opravy, které nesnesou odklad. Vidíme, že sama vznikla z větve master a také se do ní při první příležitosti vrací. Jedná se o kritické bugy způsobující padání programu apod. Teď přeskočíme na větev develop. To je hlavní vývojářská větev, kde se vyvíjí systém podle plánu. Vedle ní jsou linie „feature branches“, obsahující nové funkce, které nebyly v původním plánu zahrnuty, popřípadě nové nápady, které by si například zákazník myslel, že by bylo vhodné do systému zahrnout. Nejčastěji zde budou právě nové požadavky zákazníka. Jak můžeme vidět, linie úplně vlevo obsahuje funkci, která sice vznikla pro verzi 0.1, ale je přidaná až do verze 2.0. Je čistě na vás, kdy větve spojíte a tím přidanou funkcionalitu zveřejníte. Poslední linií, kterou jsme neprobrali, je „release“. Sem se přesune kód, který má být vydaný s další verzí. To umožňuje vývojářům pracovat na hlavní větvi (develop) a zároveň to dává druhému týmu možnost lépe odladit kód před tím, než jej vydají. Vidíme, že z release se větve spojují zpět z develop. Přeci nechceme opravit chyby a obávat se, že další verze bude obsahovat tytéž chyby . Spojením release větve zpět do develop obstaráváme to, že optimalizace a opravy již vydaného kódu budou přítomné i v další verzi.

Spojování větví

Samotné spojení větví je záležitost relativně snadná, stačí nám k tomu příkaz git merge <NazevVetve>. Po zadání tohoto příkazu se spojí zadaná větev s větví, ve které se právě nacházíme. Co se ovšem stane, nastanou-li kolize? Tady začíná skutečná zábava. Budu k vám upřímný. Řešení kolizí je ta nejhorší věc, budete ji nenávidět a nejradši byste celé PC vyhodili z okna, ale tomu byste se nevyhnuli s jakýmkoliv systémem. A přeci jen je lepší, když to na vás zakřičí, že se snažíte něco přepsat, než aby vás to pustilo a potom kolega od vedle přišel s tím, že jste mu smazali jeho celodenní práci . Git sám o sobě má celkem propracovaný mechanismus pro rozpoznávání kolizí, nebude s tím tedy tolik práce.

K této příležitosti jsem připravil menší repositář, který bude ke stažení pod článkem. První se tedy podíváme, co máme za větve.

$git branch
  DruhaVetev
  TretiVetev
* master

V každé větvi je tentýž soubor, ale s jiným textem. Ověřit si to můžete sami, buď příkazem git diff nebo přechodem do jiné větve (git checkout). Nyní zkusíme spojit větev master s druhou větví.

Auto-merging soubor.txt
CONFLICT (content): Merge conflict in soubor.txt
Automatic merge failed; fix conflicts and then commit the result.

Git nám hlásí problém se „soubor.txt“. Máme opravit konflikty a poté commitnout. Je několik způsobů, jak se ke konfliktům můžeme postavit. Jeden z nich je ručně opravit soubor, ve kterém se konflikty nacházejí. Jeho podoba se trochu pozměnila, vypadá teď následovně:

<<<<<<< HEAD
Text z prvni vetve
=======
Text z druhe vetve
>>>>>>> DruhaVetev

Vidíme text z HEAD (tedy z aktuální větve), poté text z „DruhaVetev“. Po smazání znaků, které nám k textu Git připsal, můžeme soubor přidat klasicky přes git add a poté commitnout. Tento způsob se hodí v situaci, kdy vybíráte z každé větve část.

Mergování

Další způsoby fungují na výběru verze, kterou chcete ponechat. Každý soubor má při mergování dokonce 3 verze. První verze se bere ze společného předka (nemusí být tedy vždy přítomná, například když soubor vytváříme až ve větvích) a zbývající dvě verze jsou snad jasné – je to verze z jedné a poté z druhé větve. K zobrazení jednotlivých souborů slouží příkaz git show :<verze>:<file>. Uvedeme si pár příkladů.

$ git show :1:soubor.txt
Puvodni soubor

$ git show :2:soubor.txt
Text z prvni vetve

$ git show :3:soubor.txt
Text z druhe vetve

Jak vidíme, pro první verzi souboru nám to vypsalo text v původním souboru, poté nám Git oznámil, jak vypadal soubor v obou verzích.

Bohužel jsem nepřišel na způsob, jak vzít jednu verzi a tu jednoduše použít. Nenašel jsem git příkaz, který by to podporoval. Nicméně můžeme využít samotného příkazového řádku a pomocí git show a přesměrování výstupu přepsat soubor. Prakticky se soubor sám přepíše do podoby, ve které se nacházel v jedné z větví. Například pro aplikování původní podoby souboru napíšeme git show :1:soubor.txt > soubor.txt.

Mazání větví

Nakonec si ještě řekneme jak větev smazat. Můžeme to použít například ve chvíli, kdy již větev nebudeme nadále potřebovat, protože jsme ji již zmergovali. Například v našem demu jsem druhou větev spojil s master, předal jsem do hlavní větve vše, co bylo potřeba a už s ní nadále nebudu pracovat. Ke smazání větve slouží atribut –d. Tedy větev „DruhaVetev“ smažeme příkazem git branch –d DruhaVetev.

Někdy se může stát, že jsme ve větvi, kterou jsme již zmergovali, udělali nějaké další commity. Poté nás Git již ke smazání větví nepustí. Pokud víme, že se ke commitům ve větvi dá dostat nějakým jiným způsobem (například známe hash commitu, nebo jsme si jej otagovali), můžeme použít git branch –D <NazevVetve>. Tím řekneme Gitu, ať smaže větev, i když v ní jsou ještě stále commity. Opět ale musím upozornit na již zveřejněné větve. Pokud si již někdo naclonovat váš repositář a vystavěl na vaší větvi svou aplikaci a vy mu ji poté smažete, naprosto ho tím odříznete od zbytku projektu. Proto tento způsob mazání používejte jen v situacích, kdy jste ještě větev nezveřejnili! Ušetříte tím spoustu starostí a ne jen sobě .

V demo projektu jsem smazal „DruhaVetev“, zmergoval jsem „TretiVeteve“ s „master“ a v „master“ i „TretiVetev“ poté udělal ještě jeden commit. Grafický výsledek si můžete prohlédnout níže.

V příští a zároveň poslední lekci se podíváme na vzdálený repositář a jak s ním pracovat.