Mitä laitetaan gitiin?

Ei kai nyt kukaan kehtaa julkaista paskakoodia. Menetät maineesi ja ihmisiä ärsyttää sälän julkaisu.

Olen käyttänyt oikeastaan kahta eri git-versiota: Paikallista, jossa on kaikki ja master-haaraa, jossa on pelkästään toimivaa koodia.
Paikallis-haaraan voi tehdä muutoksia esim. testata eri tavalla toteutettuja funktioita ja kun homma ei toimi pääsee takaisin toimivaan versioon. Sitten kun on testattu esim. 1-10 eri versiota valitaan niistä paras ja nostetaan se paikallishaaran pinnalle sekä tägätään master-haaran julkaisua varten.
Eikä tämä ole edes kovin monimutkainen versiohallinta-rakennelma. Versiohallintoja voi olla vaikkapa kolme ja pohjaversio voi olla vaikkapa liikkuva, jonka päälle sitten kasataan oma softa uudelleen - tällä tavalla voi vaikka vaihtaa käytetyn grafiikka-rajapinnan siten että muutokset pysyvät kuitenkin hallinnassa, jolloin voidaan ylläpitää version 1.0.x ja 2.0.x softia esim. vuoden tai pari ilman että muutoksia pääsee hukkumaan. Toisaalta saadaan pidettyä muutosten vaatima porttaus-aika minimissä kun lähestymistapa on versionhallinnan kautta systemaattinen.
Ja yritystasolla homma voi mennä sen verran monimutkaiseksi, että versionhallinnasta vastaa siihen palkattu henkilö, joka ei siis tee mitään muuta kuin pitää huolta versiohallinnoista. Perus-koodarille yleensä hommassa näkyy jokin master-haaran tägi, joka toimii alkuversiona ja integrointi "nyky" tasolle - hiukan versionhallintainsinööriltä ohjeita kysellen.

Tuolta löytyisi git-tutoriaaleista myös workflow-kuvauksia eli tilanteita joihin voi git:iä käyttäessä törmätä:
https://www.atlassian.com/git/tutorials/comparing-workflows

Perusprosessi:

1. Kirjoitetaan/muokataan testiä.
2. Testataan meneekö testi läpi, jos testi menee läpi, palaa kohtaan yksi.
3. Tee Git commit (valinnainen, committiin kirjoitettu testi)
4. Kirjoita koodia ja muokkaa sitä niin kunnes äsken kirjoitettu testi menee läpi.
5. Tee Git commit (committiin kirjoitettu testi ja muutos koodin)

Refactorointi
1. Ajetaan kaikki testit
2. Kun kaikki testit läpi niin tehdään muutos koodiin
3. Muokataan testejä että kaikki testit menevät läpi.
4. Tee Git commit, sinne teksti että mikä muutos tehty.

Uuden ominaisuuden lisääminen
1. tehdään uusi branch kyseisen ominaisuuden nimellä
2. Aloita ominaisuuden työstäminen perusprosessin mukaan
3. Kun ominaisuus valmis, mergeä ominaisuus takaisin masteriin

Muuta huomioitavaa:

-Älä tee muutoksia ympäri koodia tarpeettomasti vaan vain se asia mitä ollaan tekemässä, testi tai koodi. Minimoi RIVIT mihin muutos kohdistuu kun se versionhallinta seuraa niitä muuttuneita rivejä ja on hyvä pysyä kärryllä mitä on tullut tehtyä.

-Jos huomaa jotain hölmöä koodin tyylissä, muuttaa jonkun toiminnon nimeä tms. niin kaikki työn alla olevat ominaisuudet mergetetään takaisin masteriin ja sitten käy muutoksen koko koodille. Tämä on tärkeätä kun kimpassa tekee työtä että voi tuollaisen huollon tehdä koordinoidusti.

-Ei ole huono ajatus ennen Git:n käyttöönottoa enste leikkiä miten sitä ongelmaa ratkoo, miettiä rakenteen, miten koodin mättää ja hioa käytännöt kuntoon ennen kuin alkaa työstämään koodia, että initial commit siinä kohtaa kun luonut pohjan ja aloittaa sitten tekemään sitä testiä.