Aloittelen ohjelmointia ja teen paljon virheitä. Kannattaako jokaisen tekstitiedoston tallennus laittaa gitiin, vaikka koodi ei toimisikaan, jotta voi palata mihin tahansa versioon vai laitetaanko gitiin vain ne versiot, joissa on tehty jotain järkevää?
Mitä laitetaan gitiin?
Anonyymi-ap
9452
0Äänestä
Muut lukivat myös
Ketjusta on poistettu 1 sääntöjenvastainen viesti.
Odottaa vastausta
Näihin keskusteluihin ei ole vielä vastattu. Ole ensimmäinen.
Vastaukset 9
Vanhimmat
Ei kai nyt kukaan kehtaa julkaista paskakoodia. Menetät maineesi ja ihmisiä ärsyttää sälän julkaisu.
En tarkoita, että laittaisin julkisesti näkyville vaan ihan kotikoneellani olisi joka tallennuksesta tullut uusi versio.
Kai nyt kotikoneella voi säilöö kaikki versiot, ihan oman harkinnan mukaan.
Windows 10 urkkii koodisi! Itse koodasin kanssa kympillä. kunnes tuli vastaan tutuntuntuista koodia, tarkempi tarkastelu osoitti että siellä oli tallella vielä minun suomenkielisiä kommenttejakin.
Eikä se koodi olisi kuulunut lähteä minekkään koneeltani!
Vanha vitsi. Ketään ei kiinnosta katsella sinun lomakuviasi, joten kukaan ei niitä myöskään vakoile.
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.
"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. "
Ei käytännössä. Tiimissä näitä tehdään. Käytännössä ohjelmoija lisää ominaisuuden tekemällä uuden branchin jossa työskentelee, ja sitten nämä liitetään takaisin . Toki voidaan suunnitella että nämä ja nämä tulee versioon ja sillä aikataulu.
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ä.