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.

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.
Stáhnout
Stažením následujícího souboru souhlasíš s licenčními podmínkamiStaženo 769x (19.34 kB)
Komentáře


Zobrazeno 10 zpráv z 14. Zobrazit vše