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

Odovzdať do prednášky

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 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 master 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 master 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 master 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áre, 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.


Úlohy:

1. Dajte sa dokopy s niekoľkými ľuďmi, ktorí sedia okolo vás na cvičení (ideálne skupina v ktorej budete riešiť tímový projekt), vytvorte skupinku 4 ľudí - zatiaľ to nemusí byť tá skupina, v ktorej budete riešiť projekt TIS, ale odporúčame to.

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

3. Jeden z vás si vo svojom účte na Githube vytvorí 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. Repozitár vytvorte lokálne na svojom počítači z príkazového riadku. V repozitári budú len dva súbory - hanoi.c a readme.md (prípona md označuje, že súbor je napísaný pomocou syntaxe Markdown).

4. Skontrolujte, že repozitár na Githube je vytvorený, každý do neho môže prispievať a vidí ho: Každý člen tímu na svojom počítači a pomocou svojho githubového konta do súboru readme.md pridá svoje meno do zoznamu členov dnešného cvičného tímu a tieto zmeny pošle na Githubový server. Predtým si vytvorte na Githube vo svojom projekte jeden issue, ktorý otvoríte a uzavriete, keď túto úlohu splníte.

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

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


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

7. 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 mastera.

8. Na adresu tis-team@lists.dai.fmph.uniba.sk pošlite linku na svoj repozitár (uistite sa, že v readme.md máte svoje mená). My vám časom na tento mail odpovieme a potom tento repozitár vymažete.

9. pokúste sa zostaviť svoj tím, v ktorom budete riešiť projekt na TIS. Prezrite si popisy projektov a vyplňte informácie o svojej skupine do systému a pozadávajte vaše priority o projektoch.

Zenhub: treba si nainštalovať plugin do browsera a potom môžete prehľadne sledovať životný cyklus jednotlivých issues.

Príklady príkazov pre GIT:

Vytvorenie nového repozitára (keď ho už máte na Githube):
$ git init
$ git remote add origin http://example@exampleurl.com/repository-path
$ git push -u origin master.
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ť.

Viac si prečítajte napríklad tu: