6. diel - Git - rozdeľujte a panuj

V predchádzajúcom kvíze, Kvíz - Princípy, inštalácie a základy Gitu, sme si overili nadobudnuté skúsenosti z predchádzajúcich lekcií.

V minulom dieli nášho seriálu o gastrointestinálne sme sa venovali prezeranie histórie. To by nám nebolo príliš prínosné, keby sme nevedeli, čo máme kde hľadať. Rovnako ako obvykle, aj v súboroch musí byť poriadok. Git nám neumožňuje vytváranie priečinkov, do ktorých by sme si súbory "upratali". Prináša niečo lepšie - vetvy. Dnes sa pozrieme, ako sa s vetvami pracuje a čo nám do vývoja prinášajú.

Čo je to vetva

Keď sme v 3. diele preberali commit, spomínal som rodičia COMMIT. Vďaka rodičom môžeme zapísať vetvu. Bude to sekvencie commit, ktoré na seba nadväzujú. Commit, ktorý má dva predkov, sa nazýva merge. Tu môžu vetvy zanikať, ale nie je to pravidlom, záleží na situácii. Vetvy bude teda sekvencia commit, idúcich po sebe. Pomocou názvu vetvy sa môžeme presunúť na poslednú commit vo vetve. Názov vetvy teda funguje ako odkaz.

Vytvorenie vetvy

Vetva môžeme vytvoriť z ľubovoľného COMMIT. Ako sa presúvať medzi COMMIT sme si už hovorili, jedná sa o príkaz git checkout. Novú vetva vytvoríme cez príkaz git branch <NazevVetve>. Táto vetva bude nadväzovať na commit, v ktorom práve ste. Možno teda vytvárať aj konáre z už existujúcich COMMIT.

Čo nám vetvy prinášajú?

Pomocou vetiev môžeme projekt rozdeliť do niekoľkých paralelných sekvencií, kde každá funguje samostatne. To nám prináša veľa výhod. Hlavná výhoda je možnosť rozdeliť prácu do niekoľkých tímov, bez toho aby sa ovplyvňovali. Keď jeden tím napíše zlý kód, ktorý potom nepôjde skompilovať, ostatným tímom to nevadí. Zároveň, ak zistíme, že sme išli zlým smerom (napríklad zlý návrh programu), nie je nič jednoduchšie než vytvoriť novú vetvu z rovnakého miesta a časť kódu prepísať. Tak sa nemusíme zaoberať tým, čo už bolo napísané a hľadať, čo sme už opravili a čo ešte nie. Tak povediac, budeme mať zas čistý stôl. Zlú vetva je potom jednoduché zmazať. Vetvy tiež môžeme použiť ako takú myšlienkovú mapu.

Nápad na novú funkciu v systéme? No, tak si vytvoríme novú vetvu a implementujeme ju v tejto vetve. A keď ju chceme pridať až do ďalšej verzie? Žiadny problém, jednoducho si vetvy spojíme, ako budeme sami potrebovať. Onen nápad vlastne vôbec nebol potrebné? Nemusíme ho zmergovat a do vývoja sa teda vôbec nedostane. A keď neskôr zistíme, že by sme ho skutočne chceli zahrnúť do systému? Jediné zmergování a máme ho tam.

Aký je potom výsledok? Nie je nič jednoduchšie, než si ukázať nejaký fiktívne projekt.

Vidíme niekoľko paralelných línií. Z pravej strany je to master, ktorá je verejná a predstavuje samotný zverejnený program. K tejto vetve sa dostaneme najčastejšie. Je to vetva, ktorá sa klonom z repozitára. Vedľa nej je línia hotfixes - teda dôležité opravy, ktoré neznesú odklad. Vidíme, že sama vznikla z vetvy master a tiež sa do nej pri prvej príležitosti vracia. Jedná sa o kritickej bugy spôsobujúce padanie programu a pod. Teraz preskočíme na vetvu develop. To je hlavný vývojárska vetva, kde sa vyvíja systém podľa plánu. Vedľa nej sú línie "feature branches", obsahujúci nové funkcie, ktoré neboli v pôvodnom pláne zahrnuté, prípadne nové nápady, ktoré by si napríklad zákazník myslel, že by bolo vhodné do systému zahrnúť. Najčastejšie tu budú práve nové požiadavky zákazníka. Ako môžeme vidieť, línie úplne vľavo obsahuje funkciu, ktorá síce vznikla pre verziu 0.1, ale je pridaná až do verzie 2.0. Je čisto na vás, kedy konáre spojíte a tým pridanú funkcionalitu zverejníte. Posledný línií, ktorú sme neprebrali, je "release". Sem sa presunie kód, ktorý má byť vydaný s ďalšou verziou. To umožňuje vývojárom pracovať na hlavnej vetve (develop) a zároveň to dáva druhému tímu možnosť lepšie odladiť kód pred tým, než ho vydajú. Vidíme, že z release sa vetvy spájajú späť z develop. Predsa nechceme opraviť chyby a obávať sa, že ďalšie verzie bude obsahovať tie isté chyby . Spojením release vetvy späť do develop obstarávame to, že optimalizácia a opravy už vydaného kódu budú prítomné aj v ďalšej verzii.

Spájanie vetiev

Samotné spojenie vetiev je záležitosť relatívne jednoduchá, stačí nám k tomu príkaz git merge <NazevVetve>. Po zadaní tohto príkazu sa spojí zadané vetvu s konárov, v ktorej sa práve nachádzame. Čo sa však stane, ak nastanú kolízie? Tu začína skutočná zábava. Budem k vám úprimný. Riešenie kolízií je tá najhoršia vec, budete ju nenávidieť a najradšej by ste celé PC vyhodili z okna, ale tomu by ste sa nevyhli s akýmkoľvek systémom. A predsa len je lepšie, keď to na vás zakričí, že sa snažíte niečo prepísať, než aby vás to pustilo a potom kolega od vedľa prišiel s tým, že ste mu zmazali jeho celodennú prácu . Git sám o sebe má celkom prepracovaný mechanizmus pre rozpoznávanie kolízií, nebude s tým teda toľko práce.

K tejto príležitosti som pripravil menšie repozitár, ktorý bude k stiahnutiu pod článkom. Prvý sa teda pozrieme, čo máme za vetvy.

$git branch
  DruhaVetev
  TretiVetev
* master

V každej vetve je ten istý súbor, ale s iným textom. Overiť si to môžete sami, buď príkazom git diff alebo prechodom do inej vetvy (git checkout). Teraz skúsime spojiť vetvu master s druhou vetvou.

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ási problém so "file.txt". Máme opraviť konflikty a potom commitnout. Je niekoľko spôsobov, ako sa ku konfliktom môžeme postaviť. Jeden z nich je ručne opraviť súbor, v ktorom sa konflikty nachádzajú. Jeho podoba sa trochu pozmenila, vyzerá teraz nasledovne:

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

Vidíme text z HEAD (teda z aktuálnej vetvy), potom text z "DruhaVetev". Po vymazaní znakov, ktoré nám k textu Git pripísal, môžeme súbor pridať klasicky cez git add a potom commitnout. Tento spôsob sa hodí v situácii, keď vyberáte z každej vetvy časť.

Mergování

Ďalšie spôsoby fungujú na výbere verzie, ktorú chcete ponechať. Každý súbor má pri mergování dokonca 3 verzie. Prvá verzia sa berie zo spoločného predka (nemusí byť teda vždy prítomná, napríklad keď súbor vytvárame až vo vetvách) a zvyšné dve verzie sú snáď jasné - je to verzia z jednej a potom z druhej vetvy. K zobrazenie jednotlivých súborov slúži príkaz git show: <verzia>: <file>. Uvedieme si pár príkladov.

$ 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

Ako vidíme, pre prvú verziu súboru nám to vypísalo text v pôvodnom súbore, potom nám Git oznámil, ako vyzeral súbor v oboch verziách.

Bohužiaľ som neprišiel na spôsob, ako vziať jednu verziu a tú jednoducho použiť. Nenašiel som git príkaz, ktorý by to podporoval. Avšak môžeme využiť samotného príkazového riadku a pomocou git show a presmerovanie výstupu prepísať súbor. Prakticky sa súbor sám prepíše do podoby, v ktorej sa nachádzal v jednej z vetiev. Napríklad pre aplikovanie pôvodnej podoby súboru napíšeme git show: 1: file.txt> file.txt.

Mazanie vetiev

Nakoniec si ešte povieme ako vetva zmazať. Môžeme to použiť napríklad vo chvíli, keď už vetva nebudeme naďalej potrebovať, pretože sme ju už zmergovali. Napríklad v našom deme som druhú vetvu spojil s master, odovzdal som do hlavnej vetvy všetko, čo bolo treba a už s ňou naďalej nebudem pracovať. Na zmazanie vetvy slúži atribút -d. Teda vetva "DruhaVetev" zmažeme príkazom git branch -d DruhaVetev.

Niekedy sa môže stať, že sme vo vetve, ktorú sme už zmergovali, urobili nejaké ďalšie COMMIT. Potom nás Git už na zmazanie vetiev nepustí. Ak vieme, že sa ku commitům vo vetve dá dostať nejakým iným spôsobom (napríklad poznáme hash commit, alebo sme si ho otagovali), môžeme použiť git branch -D <NazevVetve>. Tým povieme gitu, nech zmaže vetva, aj keď v nej sú ešte stále COMMIT. Opäť ale musím upozorniť na už zverejnené vetvy. Ak si už niekto naclonovat váš repozitár a vystaval na vašej vetve svoju aplikáciu a vy mu ju potom zmažete, úplne ho tým odrežete od zvyšku projektu. Preto tento spôsob mazania používajte len v situáciách, kedy ste ešte vetva nezverejnili! Ušetríte tým veľa starostí a nie len sebe .

V demo projektu som zmazal "DruhaVetev", zmergoval som "TretiVeteve" s "master" a v "master" i "TretiVetev" potom urobil ešte jeden commit. Grafický výsledok si môžete prezrieť nižšie.

V budúcej a zároveň posledný lekcii sa pozrieme na vzdialený repozitár a ako s ním pracovať.

V budúcej lekcii, Git - Skúmanie histórie - Dokončenie , dokončíme skúmanie histórie. Budeme sa zaoberať zoznamom všetkých vetiev, detailmi commitu, sledovaním a odstránením vykonaných zmien.