Git käytännöt

Käytännöt

Branch tyypit

Brancheja on kolmen laisia:

• master: Uusin toimiva koodi, menee staging palvelimelle. Masteriin ei koskaan saa puskea suoraan, vaan ainoastaan vertaisarvioinnin läpäisseen user story pull requestin kautta. Se harhaoppinen joka rikkoo masterin kivitetään.
• User story branch: Haarautuu masterista, vastaa yhtä user storya. User storyyn pusketaan vain korjauksia konflikteihin tai todella pieniä muutoksia jotka ovat usean taskin vaatimuksina, mutta joita varten on turha tehdä kokonaan uutta branchia.
• Task branch: Haarautuu user storysta, yhtä taskia vastaava branch. Lyhyt elinkaari: haluttu muutos koodataan, testataan, ja branch pull-requestin jälkeen suljetaan.

Pull requestit

Ei koskaan pull requestia, jossa jo ennestään rikkinäistä koodia. Jos jokin menee rikki, syynä pitäisi olla kahden branchin välinen konflikti. Testien pitäisi myös travisissa osata varoittaa konfliktista jo etukäteen, vaikka konflikti onkin todennäköisesti helpointa ratkaista pull requestin jälkeen. Jos näin ei käynyt, lisää puuttuvat testit samalla kun korjaat konfliktit.

Nimeämiset

Branchien nimet aina pienellä ja yhteen. Kuvaava nimi, mutta korkeintaan kolme tai neljä sanaa. Esimerkkejä:

• User story: "AAU I can see a status page." voisi olla "statuspage" branch.
• User story: "AAU I can receive notifications from a meeting." voisi olla "meetingnotification" branch.
• Task: "Implement crude layout" voisi olla "crude" tai "crudelayout".
• Task: "Count the alarm time for the status page" voisi olla "statuspagealarm".

Workflow käytännössä

1. Valitaan task.
2. Luodaan masterista user story branch, jos ei jo olemassa.
3. Luodaan user story branchista task branch, jos ei jo olemassa.
4. Koodataan feature, koodataan testit, testataan manuaalisesti.
5. Pull request taskista user storyyn.
6. Vertaisarviointi. Katsotaan kahden tai useamman ihmisen kanssa muutokset läpi. Tehdään tarvittaessa muutoksia; pull request päivittyy automaattisesti.
7. Hyväksytään pull request ja suljetaan task branch.
8. Tarkistetaan, että toimii user storyssa. Jos ei toimi, korjataan konflikti suoraan user story branchissa.
9. Tehdään pull request masteriin.
10. Vertaisarviointi. Mikäli mikään olellinen ei ole muuttunut tämä voi olla tasolla "-Joo, toimii. Laitan tän taskin masteriin. -Okei". Muussa tapauksessa kuin kohdassa 6.
11. Varmistetaan, että toimii staging palvelimella. Palataan kohtaan 1.

Kaikki operaatiot suoritetaan alla annettujen git komentojen avulla ongelmatilanteiden välttämiseksi.

Keskustelua: Olisiko dev branch sittenkin järkevämpi kuin user story, master konfliktien välttämiseksi? Nykyisessä mallissa kaunis historia, mutta käytännön ongelmia.

Git operaatiot

Haluan ladata branchin githubista

git checkout --track origin/[halutun branchin nimi]

Haluan tehdä uuden branchin

git checkout [branch josta haaraudutaan]

git pull -r

git checkout -b [uuden branchin nimi]

(Mahdollisesti commit tai kaksi)

git push -u origin [uuden branchin nimi]

Haluan tehdä commitin

Staging:

Interaktiivinen staging

git add -i

Valitse patch

p

Valitse tiedostot

1

2

...

[tyhjä rivi]

Valitse haluamasi muutokset sitä mukaan kun muokattuja kohtia tarjotaan, tai pilko pienempiin osiin. y(yes)/n(no)/s(split)/e(edit)/...

Uudet tiedostot:

git add [tiedosto - tabilla automaattinen täyttäminen on tässä kätevä]

Commit

git commit -m "[Commit viesti]"

Jossa commit viestin pitäisi olla yhden lauseen mittainen englanninkielinen kuvaus muutoksista. Jos tarvitset kaksi lausetta kertoaksesi kaiken, tarvitset kaksi committia. Iso alkukirjain, loppuu pisteeseen. Esim. "Added an OK button to the front page." tai "Added unit tests for the front page OK button."

Haluan puskea muutokseni gittiin

1. Vain jos toimii omalla koneella.
2. Aina jos toimii omalla koneella.

Ladataan ensin mahdolliset muutokset, -r välttää turhat merget. Jos mikään ei hajonnut, puske omat muutokset.

git pull -r

git push

Haluan pullata uudet muutokset gitistä

git checkout [branchin nimi]

git pull -r

-r ei aina välttämätön, mutta ei siitä pitäisi haittakaan olla.

Sain taskin valmiiksi ja haluan poistaa branchin

git branch -D [branchin nimi]

[Parent branch] päivittyi, ja haluan muutokset omaan branchiini

• Jos branchini on jo githubissa.

git checkout [oma branch]

git merge [parent branch]

• Jos branch ei ole vielä githubissa

git checkout [oma branch]

git rebase [parent branch]

Tarvitsen välttämättä [yksittäinen commit] branchista [branch, jossa commit on]

git checkout [branch, jossa commit on]

git log

Kopioi halutun commitin hash

git checkout [oma branch]

git cherry-pick [kopioitu hash]

Haluan palata aikaisempaan committiin

Vain katselu

git checkout [commitin hash]

Uusi branch alkaen annetusta commitista

git checkout -b [uuden branchin nimi] [commitin hash]

Uusi commit, joka kumoaa annetun commitin

git revert [commitin hash]

Haluan muokata jo tehtyä committia

Historian muokkaaminen on git repojen aivokirurgiaa ruosteisella kirveellä. Vältä jos mahdollista! Githubiin puskettuun historiaan koskeminen on huono idea.

Edellisen commitin muokkaaminen:

git add [committiin haluamasi sisältö]

git commit --amend

Vanhempien committien muokkaaminen:

Vietä 15 minuuttia pohtimalla uudelleen tähän johtaneitä elämänvalintoja.