Tvorba informačných systémov - cvičenie Git a Github



Na tomto cvičení si vyskúšame prácu s git-om a Githubom. Najskôr si podrobne prečítajte celé zadanie tohto cvičenia a až potom sa pustite do práce!

Git je nátroj na zdieľanie zdrojových súborov v tímových softvérových projektoch. Je založený na myšlienke decentralizovaných rovnocenných repozitárov. Github je webová služba, ktorá poskytuje miesto, kde takéto repozitáre môžu byť uložené a môžu slúžiť ako centrálny server na ktorom sú uložené platné verzie softvéru.

Issues Github podporuje tzv. issues - čiže akýchsi "záležitostí, úloh, problémov" pri vývoji softvéru. Vývoj softvéru sa dá zorganizovať tak, že všetky činnosti, ktoré vývojový tím vykonáva, spadajú pod nejaký "issue". Softvérový tím postupne rieši jednotlivé issues, niektoré čakajú na spracovanie, vyriešenie, niektoré sú už hotové, ale ešte sa testujú, niektoré sú už vyriešené. Github dovoľuje k projektu vytvárať nové issues a evidovať, ktoré sú ešte otvorené a vyriešené. My vo vývoji projektu využijeme tento proces a všetko budeme riešiť cez issues! "Všetko" znamená, že aj dokumentáciu, aj interview so zadávateľom, celkom všetko. Nikto nesmie urobiť čokoľvek na projekte bez toho, aby na to najskôr niekto nevytvoril issue!

Na tomto cvičení budeme používať git z príkazového riadku (command line), odporúčame použiť Linux.

Základné myšlienky práce s GIT-om:

- každý vývojár má u seba (na svojom počítači) svoj kompletný repozitár projektu - so všetkými informáciami z histórie vývoja
- okrem toho má u seba vybalený jeho aktuálny stav - pracovný adresár, kde reálne súbory edituje
- repozitáre sú prepojené cez jeden ďalší repozitár na serveri Github, ktorý je prehliadateľný aj cez webový prehliadač
- zmeny v súboroch sa evidujú formou tzv. commitov - každý commit môže zmeniť jeden alebo viac súborov
- keď vývojár u seba urobí nejaké ucelené zmeny a chce ich zdieľať s ostatnými, tak označí súbory, ktoré chce dať do nasledujúceho commitu
- potom ich "commitne" do svojho lokálneho repozitára
- napokon zmeny "pushne" - potlačí do "centrálneho" repozitára na Githube
- ostatní vývojári potom "pullnú" - potiahnu zmeny do svojich repozitárov a tým zároveň aj do svojich pracovných adresárov.


Pokročilejšie myšlienky práce s GIT-om, ktoré tiež budeme používať!

- každá zmena, ktorá sa zaradí do centrálneho repozitára (tzv. master (po novom: main) branch), musí byť skontrolovaná nejakým iným vývojárom (tzv. code review), preto:
- zmeny jednotlivého vývojára sa nepushujú priamo do main branchu, ALE: vývojár, ktorý ide robiť nejaké zmeny, si najskôr vytvorí nový "branch" - vetvu vývoja softvéru, v ktorej zmeny urobí
- pochopiteľne, že tie zmeny robí na základe toho, že predtým niekto vytvoril príslušný issue - tento issue má číslo a pomocou stringu #N (napríklad #7) sa vo všetkých popisoch komitov treba na daný issue odvolávať! - tieto zmeny vykoná vo vytvorenom branchi, tie lokálne commitne a pushne na Github
- potom vytvorí pull request na zaradenie zmien, ktoré v branchi vykonal, do main branchu, mail o tom dojde ostatným vývojárom. Pull request sa vytvára priamo cez webové rozhranie Github-u
- ostatní vývrojári môžu zmeny komentovať, autor kód ďalej upravovať až napokon, keď to niekto znovu skontroluje, tak môže urobiť merge do main branchu
- proces pokračuje v takomto cykle ďalej, naraz môže byť editovaných aj viacero branchov, ak sa týkajú iných súborov, alebo iných častí súboru
- ak sa merge-ujú branche, ktoré sa líšia na rovnakých miestach, tak dôjde ku konfliktu - rozdiely sa vyznačia priamo v zdrojáku, ten treba ručne poopravovať (zlúčiť zmeny) a znovu označiť (add), commitnúť a výsledok pushnúť - každý "branch" je vlastne len pointer na nejaký commit do postupnosti (orientovaného necyklického grafu) commitov, pozri: Git Basic Branching and Merging.


Ako funguje git?
Local Remote
unstaged staged commited remote repository
  1. Všetky lokálne zmeny (nové súbory/adresáre, upravené súbory, premenované súbory/adresáre, zmazané súbory/adresáre) sú v stave unstaged.
  2. Pomocou git add, git mv a git rm presúvame zmeny zo stavu unstaged do stavu staged.
  3. Všetky súbory v stave staged sú pripravené na nadchádzajúci commit.
  4. Ak vykonáme zmenu v súbore/adresári, ktorý je v stave staged, zmena sa automaticky nezapíše do stavu staged a bude teda unstaged, dokial sa nepoužije git add, git mv alebo git rm. To znamená, že vždy treba znovu označiť súbor po zmene aby sa dostal do stavu staged.
  5. Zo stavu staged do stavu commited sa presunú súbory po vykonaní git commit.
  6. Aby sa lokálne commity zo stavu commited dostali na remote repository, treba vykonat git push.
  7. Niekedy máme v pracovnom adresári zmeny, ktoré nechceme celkom stratiť, ale potrebujeme ich odložiť a vrátiť sa do posledného platného stavu podľa posledného commit-u. Vtedy tie zmeny môžeme odložiť do stavu "stashed" (aj viackrát) a neskôr vrátiť späť. S týmto treba narábať opatrne, ale slúži na to príkaz git stash.


Úlohy:

1. V tomto cvičení budete pracovať už vo svojej skupine (4 ľudia). Ak niekto z Vás nemôže byť prítomný, nájdite si iný čas, kedy cvičenie vypracujete, alebo to urobte postupne.

2. Každý z vás si vytvorí svoj účet na serveri Github, ak už máte, použite ten.

3. Ak ste na Linuxe, nainštalujte si git, napr. pomocou sudo apt install git, ak ste na Windows, downloadninte si git pre Windows: Git for Windows

4. Jeden z vás si vo svojom účte na Githube vytvorí nový repozitár a pridá do neho ostatných členov skupiny. Tento repozitár bude len cvičný a po skontrolovaní výsledkov cvičenia ho zmažete. Keď na githube repozitár vytvoríte, všetci si hneď vyklonujte tento repozitár u seba na svojom počítači. Otvorte príkazový riadok (alebo vo Windows kliknite v nejakom adresári pravou myšou na "Git bash here") a zadajte git clone ADRESA_REPOZITARA - adresu repozitára získate na Githube ( zelené tlačidlo "Code").

5. Ďalší z Vás do svojho vyklonovaného repozitára pridá nasledujúce dva súbory: Súbor readme.md zedituje (pridá svoje meno do zoznamu). Následne oba súbory cez git add readme.md hanoi.c pridá do staged a potom komitne (git commit). Po každom príkaze si zobrazujte stav repozitára pomocou git status. Pri komitovaní treba zadať krátku správu o tom, čo je v súbore nové, zmenené - tieto správy sú dôležité, aby ste sa neskôr v komitoch vyznali a vedeli nájsť zmeny, ktoré budete hľadať. Ak sa vám otvorí etditor VI (skratka od Visual), tak budete musieť správu napísať v ňom a nakoniec (napr. pomocou :wq vyskočiť von z editora). Po komitnutí nakoniec zmeny push-ne na Github (git push). Tu budete musieť zadať githubové údaje - e-mail a heslo a zrejme počas tohto procesu niekedy bude git žiadať, aby ste nastavili na počítači, alebo v tomto repozitári githubov-é autentifikačné údaje používateľa, ktorý komituje.

6. Skontrolujte, že repozitár na Githube je vytvorený a súbory, ktoré ste pridali, tam sú. Následne si všetci ostatní zmeny, ktoré urobil prvý z vás (pridané súbory) vytiahnu aj k sebe do svojej kópie repozitára (git pull) a potom skontrolujú, že vo svojom pracovnom adresári tieto súbory majú.

7. Všetci traja, ktorí ešte v súbore nemajú svoje mená si ich tam vo svojom pracovnom adresári naraz - nezávisle od seba pridajú, potom súbor pridajú do staged (git add readme.md), komitnú (git commit) a nakoniec push-nú (git push) - ale pozor, pred každým pushnutím by sme mali najskôr pull-núť prípdané zmeny, ktoré na serveri sú. Ak to aj neurobíme a nejaké zmeny tam už sú, tak sa nám to nepodarí a najskôr musíme pull-núť (git pull). Avšak - keďže ten, čo na server dal svoje zmeny ako prvé editoval vo svojom komite ten istý súbor ako ostatní, git pull sa nepodarí a vyhlási, že došlo ku konfliktu, súbor v pracovnom adresári rozsype - dá do neho značky <<<<< a >>>>> a =====, ktorými označí časti súboru z jednotlivých verzií. Preto teraz treba tento súbor ručne otvoriť v editore, zeditovať do takej podoby akú má mať a potom znovu add-núť, komitnúť a nakoniec push-núť na Github.

8. Keď budete mať takýmto spôsobom na Githube kompletný súbor readme.md, tak sa môžete pustiť do opravy suboru hanoi.c.

9. V súbore hanoi.c sú dve chyby. Nájdite ich a postupne po jednej ich opravte. Aktualizovanú verziu nahrajte na Github z niektorého konta. Celé to prebehne takto:

9.1. vytvorte issue "oprava hanoi"
9.2. jeden z vás - C1 - (ten, čo vie s Gitom pracovať najmenej) vytvorí u seba nový "branch" tohto projektu
9.3. v tomto branchi urobí potrebné úpravy a pošle ich na Github
9.4. z prehliadača na Githube urobí pull request, aby sa zmeny z jeho vytvorenej vetvy zaradili naspäť do "main" branchu a napíše k tejto požiadavke komentár
9.5. Druhý člen tímu C2 si zmeny pozrie a napíše ku zmenám iba svoj komentár.
9.6. Tretí člen tímu C3 urobí to isté ako druhý člen.
9.7. Štvrtý člen tímu C4 zmeny z branchu zahrnie do main branchu a tiež nechá komentár.


10. Skontrolujte, ako vyzerá repozitár na Githube, vizuálne porovnajte rozličné verzie súboru hanoi.c

11. Tento proces zopakujeme ešte raz - člen C2, ktorý len vytváral komentár, si teraz vytvorí svoj branch, urobí v súbore zmenu, aby texty, ktoré program vypisuje, boli v slovenčine, ale urobí pritom chybu a pošle pull request a člen C3 vytvorí komentár, kde popíše aká chyba v tomto novom branchi je. Člen C1 v tejto branchi urobí opravu a pridá o tom komentár. Člen C3 urobí merge branchu do main.

12. Na adresu petrovic@fmph.uniba.sk pošlite linku na svoj repozitár (uistite sa, že v readme.md máte svoje mená) a súbor hanoi.c je správny. My vám časom na tento mail odpovieme a potom tento repozitár vymažete.



Príklady príkazov pre GIT:

Vyklonovanie repozitára (keď ho už máte na Githube): 
$ git clone
Vytvorenie novej branch z aktuálnej branch (a zároveň prepnutie na tútu branch): 
git checkout -b nazov_branchu
Prepnutie lokálneho pracovného adresára na iný branch: 
git checkout nazov_branchu
Zistenie stavu aktuálneho pracovného adresára: 
git status
Zistenie rozdielov aktuálneho pracovného adresára oproti lokálnemu aktívnemu branchu: 
git diff
Za oba príkazy môžete pridať aj názov súboru alebo adresára...

Označenie súboru pre ďalší commit: 
git add meno_suboru
Premenovanie alebo presun súboru či adresára: 
git mv meno_suboru nove_meno_suboru
Vymazanie súboru alebo adresára: 
git rm meno_suboru
Odstránenie súboru zo stavu staged a vymazanie cesty z indexu (súbor ostane lokálne nedotknutý ale pre ďalší commit sa zaradí ako zmazaný): 
git rm --cached meno_suboru
Príkazy git add, git mv a git rm zapisujú zmeny do staged area pre nasledujúci commit.

Navrátenie súboru do pôvodného stavu (pre súbory v stave not staged for commit): 
git checkout -- cesta_k_suboru
Vyradenie súboru z dalšieho commitu (staged -> unstaged): 
git reset HEAD cesta_k_suboru
Commitnutie označených súborov (realizovnie commitu): 
git commit
Pretlačenie zmien z lokálneho repozitára na Github: 
git push
Potiahnutie zmien z repozitára na GitHube do lokálnej kópie repozitára: 
git pull
Zobrazenie záznamu zmien (v aktuálnej branch): 
git log
Zobrazenie záznamu zmien pre všetky branche naraz: 
git log --all
Zobrazenie iba commit message v zázname zmien: 
git log --oneline
Zobrazenie dodatočných informácií v zázname zmien: 
git log --decorate
Zobrazenie grafu zmien v zázname zmien: 
git log --graph
Všetky optional parametre príkazu git log je možné samozrejme kombinovať.

Zobrazenie lokálne evidovaných branchov: 
git branch
Označenie niektorých súborov, aby zmeny v nich nebral do úvahy: 
git stash
(potom môžeme urobiť git push, pull, commit) a keď chceme zmeny znovu vrátiť, aby sme mohli pokračovať v práci: 
git stash show
git stash list
git stash pop
V priečinku repozitára si môžete vytvoriť súbor .gitignore so zoznamom súborov, ktoré si git nemá všímať a tým pádom sa nedostanú do repozitára. Je to vhodné napr. na binárne súbory, alebo dátové súbory, ktoré nechcete evidovať (do repozitára by sa mali vkladať iba zdrojové súbory a prípadne vstupné dátové súbory a dokumentácia).

Viac si prečítajte napríklad tu: