Versionhallinta – GIT-harjoitukset

Nämä harjoitukset jakautuvat kahteen osaan: etukäteen yksin tehtäviin, ja pajassa ryhmässä tehtäviin. Pahoittelemme "branchi repositoryn trunkista" -kieltä, suomennokset eivät ole vakiintuneet tai niitä ei ole.

Tehtäviä tehdessä on paras lukea Git Community Bookia. Vastaukset tehtäviin ovat siellä.

Myös aina hyödyllisiä ovat man-sivut. Gitin tapauksessa komentokohtaiset man-sivut aukeavat komennolla man git-komento, esim. komennon git init man-sivu on git-init.

ETUKÄTEEN, eli ennen ohjattua ryhmätehtäväpajaa

Etukäteistehtävät eivät ole vitsi: jos alat tekemään niitä vasta ryhmätehtäväpajassa, et ehdi tekemään ryhmätehtäviä. Jos muut ryhmäläiset ovat tehneet etukäteistehtävät, he alkavat tekemään ryhmätehtäviä etkä pysy mukana ja käytännössä loisit ryhmän mukana oppimatta mitään.

Git-intro

Jos olet aiemmin käyttänyt eri versionhallintaa (kuten SVN), mutta tietty muutenkin: tässä lyhyt Git-filosofia. Pidempi filosofia löytyy kurssin vanhoista Git-luentokalvoista.

Git ei ole perinteinen verionhallinta, vaan työkalu oman versiointityönkulun rakentamiseksi. Git on myös tiedostojärjestelmä. Git on MacGyver.

Git on hajautettu: jokainen työkopio on samalla repository (joka usein on kloonattu toisesta repositorysta komennolla git clone). Commitit menevät aina paikalliseen repositoryyn (nopeaa), josta ne tarvittaessa pushataan mahdolliseen emo-repositoryyn (esim. GitHub).

Gitissä on työkopion/hakemiston lisäksi indeksi, johon kerätään commitoitavat tiedostot. Aloittelijan hyvä git-perustyönkulku on seuraava looppi.

1. git pull (hae mahdolliset muiden tekemät muutokset emo-repositorysta)
2. (tee työkopiossa sopiva paketti muutoksia, esim. backlogin seuraava kohta)
3. git add [tiedostot] (lisää muokatut/uudet tiedostot indeksiin)
4. git commit -m "fixed issue: megatron too small"
5. git push

Kohdan kolme (git add) voi enimmäkseen ohittaa, eli Gitiä voi käyttää SVN:n tapaan ilman indeksiä:

1. git pull
2. (tee työkopiossa paketti muutoksia)
3. git add [uudet tiedostot] (lisää ainoastaan uudet tiedostot indeksiin)
4. git commit -a -m "fixed issue: megatron still too small"
5. git push

Oheinen kuva ja sen takana oleva linkki valottaa asiaa.

Git-näppäilyä

Tee etukäteen nämä komentorivi- ja Git-näppäilyharjoitukset, niin harjoituksissa tajuat mistä on kyse.

1. Kirjaudu koneelle users.cs.helsinki.fi. Myös legacy-alias db toimii.

2. Jos kyllästyttää naputtaa jatkuvasti salasanaa (kotikoneelta kirjautuessa), niin tee itsellesi SSH-avain. Laitoksen koneilta toisille pääsee nykyään automaattisesti ilman salasanakyselyä.

3. Luo tyhjä git-repository käyttäen komentoa git init --bare REPOSITORYN_NIMI. Huomaa --bare; ilman sitä repositoryyn pushaus ei oletuksena toimi!

4. Voit tehdä repositoryn mille koneelle tahansa, mutta suosittelemme hallittavuuden ja harjoituksen vuoksi, että

   1. alkuperäinen repository on koneella users.cs, jossa on erillinen kotihakemisto, ja
   2. repositoryn työkopio(t) omassa laitoksen kotihakemistossasi.

5. Ota repositorysta itsellesi työkopio nykyiselle koneelle komennolla git clone, käyttäen ssh:// -URLia (on oletus, joten "ssh://" voi jättää pois).

   • Jos olet laitoksen mikroluokassa kirjautuneena laitoksen koneelle, työkopio tulee laitoksen kotihakemistoosi.
   • Laitoksen koneilla ei myöskään kysytä salasanaa, koska edelleen kirjautuminen users.cs-koneelle tapahtuu automaattisesti. Tämä on erityisen hyvä, koska jatkossa teemme paljon push- ja pull-operaatioita users.cs-koneelle.
   • Virhe: fatal: '~SAMPUMON/git/megatron.git' does not appear to be a git repository – Todennäköisesti URL on väärin. Ks. "man git-clone", selaa alaspäin "GIT URLS".

6. Konffaa (aseta/konfiguroi) työkopion git-asetukset: nimi ja email.

   • git config --list listaa asetukset.
   • user.email on sähköpostiosoitteesi. Esim. GitHub käyttää sitä käyttäjä-id:nä, jonka perusteella commitit yhdistetään GitHub-käyttäjään.
   • user.name kuuluu olla koko nimesi, ei käyttäjätunnus.
   • Esim: git config user.name "Sampumon Megatron"
   • Voit (ja kannattaakin) asettaa nämä globaaleiksi: git config --global ….

7. Lisää työkopioon tiedosto. Esim. echo initial nugget >> nuggets.txt.

   • git status näyttää, mitä muutoksia työkopiossa on, joita ei ole vielä commitoitu.

8. Jännittävä vaihe: add, commit, push.

   • Lisää työkopioon lisäämäsi tiedosto gitin indexiin. Lainaus man git-add:

     This command updates the index using the current content found in the working tree, to prepare the content staged for the next commit. …

     The "index" holds a snapshot of the content of the working tree, and it is this snapshot that is taken as the contents of the next commit. Thus after making any changes to the working directory, and before running the commit command, you must use the add command to add any new or modified files to the index.

   • Commit vaatii parametrilla -m annettavan commit messagen. Jos yrität commitoida ilman viestiä, joudut vim-editoriin josta ei pääse pois.
   • Ensimämisellä kerralla pushattava branch on määriteltävä, eli käytännössä: git push origin master. Jatkossa pelkkä push riittää.

9. Kun sait edellisen tehtyä (push meni läpi), kokeile:

   • git remote -v kertoo, mistä repositorysta tämä työkopio-repository pullataan (fetch) ja mihin pushataan (yleensä sama kuin fetch).
   • git branch -a listaa paikalliset (local) ja etä (remote) branchit. Tähti * merkkaa työkopioon tällä hetkellä haettua (checkout) branchia.

10. Kokeile myös graafisella git-työkalulla mitä on tullut tehtyä. Valitse mieluisin seuraavista.

    • gitk (Ubuntu ja OS X), mainio legacy-gui
    • gitg tai giggle (Ubuntu)
    • gitx (OS X)

11. Ota repositorysta työkopio jollekin toiselle koneelle, esim. kotikoneelle. Komento on sama kuin aiemmin.

12. Lisää repositoryyn kamaa toisen työkopion kautta ja hae muutokset (pull) ensimmäiseen työkopioon.

13. Jatka kokeilua, kunnes tunnet olosi kotoisaksi.

Tutustu tehtäviin

Selaa tehtävät etukäteen ja kokeile tarvittavien komentojen käyttö jo ennen harjoituksia. Kokeiltavia komentoja:

• git log --stat, git log --graph
• git diff, git diff HEAD^ HEAD
• git difftool --tool=meld ... suorita sama diff ulkoisella diff-työkalulla, (laitoksen) Ubuntuissa Meld.
• git branch, git checkout, git merge. Ks. Git Book.

Pajan ryhmätehtävät

Muodostetaan kolmen (3) hengen pienryhmiä ja tehdään tehtävät. Kahden hengen ryhmä on ok, neljän hengen ei.

Ryhmän yhteinen repository

Luokaa ryhmällenne yhteinen emo-repository. Käytönnössä yksi ryhmäläisistä luo repositoryn koneelle users.cs ja antaa muille ryhmäläisille luku- ja kirjoitusoikeudet repositoryyn.

Vain yksi ryhmäläinen tekee (mutta yhdessä parikoodaten muiden kanssa)

1. Luo jaettu emo-git-repository koneen users.cs kotihakemistoosi. Käytä komentoa: git init --bare --shared=0666 REPOSITORYN_NIMI. Näin repositoryn tiedostoille tulee (nyt ja jatkossa) luku- ja kirjoitusoikeudet kaikille.

   • Oikeassa käytössä oikeudet tulisi antaa vain sille ryhmälle, joka käyttää repositorya. Esim. ohjelmistotuotantoprojektissa ryhmää varten muodostetaan ylläpidon toimesta unix-ryhmä, joka korvaa laitoksen oletusryhmän tktl, ja johon kuuluu vain kyseisen ohtuprojektin jäsenet.
   • Nyt kuitenkin annetaan oikeudet kaikille (sekä group että others), jotta muodostamamme adhoc-ryhmän jäsenet, niin pää- kuin sivuaineopiskelijat, pääsevät käsiksi repositoryyn.
   • Mielenkiintoinen advanced-huomio (ns. tulipa kokeiltua): jos repositorya ei luo --shared -parametrilla, vaan asettaa tiedosto-oikeudet käsin: chmod -R a+rwX, niin oikeudet asetetaan vain kerran ja jatkossa uusille tiedostoille/hakeistoille tulee umaskin mukaiset oletusoikeudet, eikä siten kirjoitusoikeuksia muille. Git-repository on kuitenkin luonteeltaan write-only, ja toimii chmod-menettelyllä kunnes ensimmäistä kertaa hakemistossa objects hashin kaksi ensimmäistä merkkiä törmäävät, ja uusi blob yritetään kirjoittaa jo olemassa olevaan hakemistoon, johon ei ole kirjoitusoikeutta jos se on jonkun muun ryhmäläisen commit/pushin johdosta luotu.

2. Anna myös hakemistoon siirtymisoikeudet (chmod a+x) koko hakemistopolulle luomaasi git-repositoryyn, alkaen users.cs -koneen kotihakemistostasi. Eli jos repositoryn polku on /home/sampumon/git/megatron.git, anna a+x -oikeudet lihavoiduille hakemistoille.

   • Tämä on sama kuin mitä piti tehdä, jotta oman public_html -hakemistonsa (eli "kotisivun") sai näkymään internetiin, mutta nyt se on tehtävä uudestaan koska users.cs -koneella on eri kotihakemisto.

3. HOX! Jos alla repositorya kloonatessa tulee virhe fatal: '~sampumon/git/megatron.git' does not appear to be a git repository ja ls -la ~ näyttää users.cs-koneella kotihakemiston oikeusrimpsun lopuksi +-merkin, niin hakemisto-oikeuksia tulee hieroa lisää. Toimi näin:

   1. Lisää komennolla setfacl -m group::--x,other::--x ~ ~/git läpikulkuoikeuden tarvittaviin hakemistoihin users.cs-koneella.
   2. Kokeile git clone uudestaan!

Kaikki (myös repositoryn luonut) ryhmäläiset tekevät

1. Hae yllä luodusta ryhmän yhteisestä repositorysta itsellesi omalle koneellesi työkopio SSH:n yli.

   • Komento on tuttu git clone, mutta URL on oleellisesti eri, koska repository ei ole omassa users.cs-kotihakemistossasi (paitsi repositoryn luoneella kaverilla).
   • Jos repository on käyttäjän SAMPUMON kotihakemistossa kuten yllä chmod-esimerkeissä, ja sinun käyttäjätunnuksesi on KTUNNUS: git clone KTUNNUS@users.cs.helsinki.fi:~SAMPUMON/git/megatron.git.
   • Nyt kun asia esimerkin muodossa tuli puheeksi: tykkäisin, jos voisin vaihtaa laitoksen käyttäjätunnuksekseni sampumon.

2. Lisätkää repositoryyn yksi tiedosto ja kokeilkaa, että saatte sen commitoitua ja pushattua, sekä pullatkaa muiden tekemät muutokset.

3. Valmis! Tätä ryhmän yhteistä repositorya käytetään kaikissa lopuissa tehtävissä.

Commit-conflict: kissan venytys

On annettu "Shortcat".

	    /\___/\
	   /       \
	  |  #    # |
	  \     @   |
	   \   _|_ /
	   /       \______
	  / _______ ___   \
	  |_____   \   \__/
	   |    \__/
	   |       |
	   /        \
	  /   ____   \
	  |  /    \  |
	  | |      | |
	 /  |      |  \
	 \__/      \__/
	
		Shortcat.
	

1. Yksi ryhmän jäsen laittaa Shortcatin repositoryyn tiedostoon shortcat.txt.

2. Muut ryhmän jäsenet pullaavat Shortcatin. Kannattaa varmaan pitää kissaa jatkuvasti auki tekstieditorissa. Ubuntussa suosittelemme gedit-editoria. Se raportoi, jos tiedostoa on muokattu (esim. git pullin toimesta), niin et vahingossa muokkaa vanhaa versiota.

3. Jokainen ryhmän jäsen pidentää oman työkopionsa Shortcattia keskikohdasta yhdellä |OMANIMI| -rivillä (korvaa OMANIMI etunimelläsi), pidennyksen jälkeen kukin tekee commit&pushin yhteiseen repositoryyn. Tehkää tämä samanaikaisesti siten, että committeja tulee jokaiselle ainakin kaksi kappaletta. Shortcatin mahan pituudeksi tulee tällöin 1 + [ryhmässä jäseniä kpl] * 2.

   Komennot per ryhmäläinen ovat siis: pull + 2x( [kasvata mahaa]+add+commit+pull+push ).

   Selvittäkää ristiriidat (conflict) venytyksen edetessä. Ristiriitoja tulee, se on tehtävän tarkoitus! Jos kahden commit&pushin per jäsen jälkeen EI tullut ristiriitaa, jatkakaa venytystä. Nopein ryhmäläinen ei välttämättä saa ristiriitoja ratkaistavakseen (vaan aiheuttaa niitä muille). Tässäkin tapauksessa on suositeltavaa jatkaa mahan pidennystä, kunnes jokainen ryhmäläinen on päässyt ratkaisemaan yhden ristiriidan.

   

4. Selvitä git blame -komennolla, kuka on lisännyt minkin rivin shortcat.txt -tiedostoon.

5. Uudelleennimetkää tiedosto longcat.txt:ksi, sillä shortcat on nyt looooooooooooong. Katso git status -komennolla, havaitsiko Git uudelleennimeämisen.

6. Katso graafisella Git-työkalulla, miltä repositoryn historia näyttää. Laitoksen Ubuntuilla gitk tai gitg tai giggle. Onko longcat.txt-nimeä edeltävä historia tallessa?

Branch ja merge

Tehkää ryhmässänne seuraava tehtäväjako: yksi ryhmäläinen muokkaa Longcatin päätä, toinen mahaa ja kolmas jalkoja. Esim. ruumiinosia voi leventää/pidentää ja commit-viestissä ilmoitetaan mitä tehtiin. Kannattaa varmaan sopia yksikäsitteiset muokkausrajat, jos ette enää halua ratkoa merge conflicteja.

Seuraavaksi seuratkaa oheisia ohjeita sekä Git Bookin branch-ohjeita.

1. Jokainen ryhmän jäsen tekee master -branchista oman etunimensä mukaan nimetyn branchin.
2. Vaihda luomaasi etunimi-branchiin. Branchin luominen (yllä) ei vaihda työkopion nykyistä branchia.
3. Muokkaa branchisi Longcatia aiemman tehtäväjaon mukaan. Commit kun on valmista.
4. Pushaa branchisi ja varmista, että muut ryhmäläiset näkevät sen.
5. Mergeä valmis etunimi-branchisi master -branchiin.
6. Tee master -branchista tag valmis-ETUNIMI.
7. Pushaa tagisi ja varmista, että muut ryhmäläiset näkevät sen.
8. Katso komennolla gitk/gitg/giggle mitä tuli tehtyä.
9. Pushaa mergetty versio master-branchista.
10. Poista äsken masteriin "hyväksytty" etunimi-branchisi.
    • Ainoastaan branchin paikallinen viite poistetaan. Branchi jää yhä emo-reposotoryyn ja siihen säilyy remote-viite paikallisessa repositoryssa, ja niin kuuluukin. Myös remote-branchin voi poistaa, mutta operaatio hukkaa branchin nimen verran historiaa.
11. Kun kaikki ryhmäläiset ovat valmiita ja pushanneet, pullaa ja katso taas mitä tuli tehtyä. Kaikilla ryhmäläisillä pitäisi olla samanlainen kissa.

Ignore

1. Lisää oheinen Longcat.java työkopioon ja käännä se (javac Longcat.java).
2. Lisää samaan hakemistoon .gitignore -tiedosto siten, että .class -tiedostot pysyvät poissa versionhallinnasta.
3. Lisää (kaikki) uudet tiedostot kerralla indeksiin: git add -A.
4. Commit & push.

Graafiset työkalut

Tutustu seuraaviin. Näillä on jo aiemmissa tehtävissä katsottu repositoryn tilaa, mutta ohjelmilla voi myös tehdä muutoksia. Kokeile muokata tiedostoa ja suorita sitten commit & push valitsemallasi graafisella työkalulla.

GIT GUI: gitk / git gui, giggle (laitoksen Ubuntu), gitx (OS X) / gitg (Ubuntu).

DIFF GUI: meld (Ubuntu), filemerge (OS X).

GitHub

Siirtäkää ryhmänne repository GitHubiin. Tämä on helppoa, koska Git on ihana!

1. Tehkää GitHub-tunnus. Ainakin yksi tunnus tarvitaan.
2. Luokaa GitHubiin uusi repository. Seuratkaa GitHubin ohjeita.
3. Yksi ryhmäläinen pushaa ryhmän nykyisen repositoryn GitHubiin. Ihan sama kuka, nykyiset repositoryt ovat samanarvoisia.
4. Jokainen lisää työkopio-repositorynsa remoteksi GitHub-repositoryn. Nyt emo-repositoryja on kaksi: users.cs-repository ja GitHub-repository. Huh? Ks. git remote -v
5. Jokainen tekee muutoksen ja pushaa sen GitHub-remoteen (ei users.cs-remoteen). Mitä pitää tehdä, jotta saa kirjoitusoikeuden GitHub-repositoryyn?
6. GitHubista löytyy myös tuttuja, esim. Sampumonin muumi-dl.

Ps. itse aloin tajuta kuinka Git toimii vasta alettuani tosissani käyttää GitHubia. Pps. GitHubista saa opiskelijatunnuksia, joihin saa myös privaatteja repositoryja.

Hooks

Tehtävä komentorivi-ihmisille!

1. Laita omaan repositoryyn hook, joka lähettää sähköpostia pushin jälkeen. Komento mail.
2. Laita omaan repositoryyn hook, jolla saat päivitettyä sisällön nettiin, eli laitoksen kotihakemistosi public_html -hakemistoon.

Muita toimintoja

TODO näitä ei tehdä. Näitä tehdään jos ehditään ja/tai tuntuu, että osaa aikaisemmat jo riittävän hyvin. Näitä ei tarvitse osata harjoitustyössä. Harjoitustyötä ei ole.

1. Käyttäkää git rebase -i -komentoa: yhdistäkää, pilkokaa ja uudelleenjärjestelkää committeja.
2. Palauttakaa aiempia committeja git reflog -komennon avulla.
3. Kokeilkaa git stash -komentoa.
4. Käyttäkää Gitillä jotain SVN-repositorya.
5. Käyttäkää patcheja: git format-patch, git am, myös git apply