Workflow

Projektin aloitus

1) Yksi ryhmäläisistä luo projektin jossa on pelkkä README.md version.aalto.fi:hin ja kloonaa sen. Projektin pohja kopioidaan repositoryyn tai luodaan sbt:llä sen alle.

2) projektin tiedostot lisätään projektiin (add) ja viedään yhtenä committina repositoryyn.

3) muutokset viedään version.aalto.fi:hin: ** git push**

4) ryhmäläiset hakevat itselleen kopiot (git clone)

Vaihtoehtoisesti (jo olemassaoleva projekti):

1) Yksi ryhmäläisistä luo jo olemassaolevan projektin kansioon luodaan tyhjän repositoryn komennolla git init ja luo version.aalto.fi:hin uuden tyhjän projektin. Tämä jälkeen hän asettaa komennolla git remote add (katso git ohje) projektin etärepositoryksi version.aalto.fi:ssä olevan projektin.

2) projektin tiedostot lisätään projektiin (add) ja viedään yhtenä committina repositoryyn.

3) muutokset viedään version.aalto.fi:hin: ** git push**

4) ryhmäläiset hakevat itselleen kopiot (git clone)

Työskentely projektissa

1) Aina aloittaessaan työt on hyvä idea hakea viimeisin versio jonka muut ryhmäläiset ovat vieneet version.aalto.fi:hin. Tämä tapahtuu komennolla git pull.

2) Tehdään jokin mielekkään kokoinen parannus projektiin.

3) Viedään muutos talteen paikalliseen repositoryyn komennoilla git add ja git commit.

4) Vielä ennen muutosten viemistä version.aalto.fi:hin tehdään kerran git pull ja liitetään muiden tekemät muutokset omiin mikäli syntyi ns. merge conflict. (esitellään luennolla)

5) Lopuksi viedään muutos muiden ryhmäläisten käyttöön komennolla git push

Laadukkaat commitit

Kaikkien työ on helpompaa, kun pelataan yhteisillä pelisäännöillä. Yksi olennainen osa ovat laadukkaat commit:it. Hyvä commit on muuttaa yhtä asiaa ja sillä on selkeä commit-viesti.

Jotta commit:it pysyvät pieninä ja selkeinä, on usein hyvä idea keskittyä yhteen asiaan kerrallaan ja viedä sen muutokset talteen mahdollisimman pian. Commit Early - commit often.

Viestin tulisi alkaa max 50 merkin otsikolla, joka kirjoitettaan imperatiivimuodossa ja jonka lopussa ei ole pistettä. Jos viesti on pidempi, tulee tämän jälkeen tyhjä rivi ja pidempi selittävä teksti. On tärkeämpää kertoa mitä on muutettu ja miksi, kuin kertoa kuinka se on tehty.

esim `git commit -m "Fixes bug #13 which prevented new users from editing their profiles"

Never push broken code to master

Master-haaraan ei tulisi koskaan lähettää koodia, jossa on bugeja. Se vaikuttaisi tarpeettomasti kaikkien muiden kehittäjien töitä, koska jokainen saisi sieltä omaan repoonsa nuo virheet seuraavan git pull-komennon yhteydessä. Koska git on hajautettu järjestelmä, voit aina tehdä työtä omassa repossasi, kunnes koodi on lähettämiskunnossa.