-
Notifications
You must be signed in to change notification settings - Fork 2
Git käytännöt
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.
Branchin 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".
- Valitaan task.
- Luodaan masterista user story branch, jos ei jo olemassa.
- Luodaan user story branchista task branch, jos ei jo olemassa.
- Koodataan feature, koodataan testit, testataan manuaalisesti.
- Pull request taskista user storyyn.
- Vertaisarviointi. Katsotaan kahden tai useamman ihmisen kanssa muutokset läpi. Tehdään tarvittaessa muutoksia; pull request päivittyy automaattisesti.
- Hyväksytään pull request ja suljetaan task branch.
- Tarkistetaan, että toimii user storyssa. Jos ei toimi, korjataan konflikti suoraan user story branchissa.
- Tehdään pull request masteriin.
- 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.
- 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 checkout --track origin/[halutun branchin nimi]
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]
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ä]
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."
- Vain jos toimii omalla koneella.
- 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
git checkout [branchin nimi]
git pull -r
-r ei aina välttämätön, mutta ei siitä pitäisi haittakaan olla.
- 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]
git checkout [branch, jossa commit on]
git log
Kopioi halutun commitin hash
git checkout [oma branch]
git cherry-pick [kopioitu hash]