Arendus kasutades Git harusid
Giti harud
Haruks (inglise keeles branch) nimetatakse versiooni/snapshoti rakenduse lähtekoodist.
Main branch (või ka master) on see haru, kus reeglite kohaselt peaks olema viimane versioon korralikult töötavast ja põhjalikult läbi testitud rakendusest. Sinna otse kunagi koodi ei pushita ning selle rakendamiseks kasutatakse kaitsemeetmeid.
Enne koodi kirjutamise alustamist luuakse tavaliselt main branchi põhjal “koopia”, mida nimetatakse feature branchiks. See on justkui arendaja isiklik liivakast, kus ta võib arendada uut või kustutada vana funktsionaalsust või katsetada mingit lahendust mõjutamata põhiharus oleva koodi põhjal ehitatud rakenduse toimimist, mida võibolla parasjagu kasutavad reaalse maailma kliendid.
Tihti lisatakse lisaturvalisuse eesmärgil veel main ja feature branchide vahele development branch, kuhu koondatakse kokku muudatused enne main/master branchi lisamist, et siis neid koos testida ja veenduda, et sinna jõudev kood oleks tõesti lollikindel.
Harude haldamine Gitlabis
Harusid saab Gitlabis näha ja hallata siit:
Uue branchi saab luua siit:
Selleks, et see endale kohalikku arvutisse saada ning koodi hakata kirjutama, tuleks see fetchida ja checkoutida
Hea tava on luua iga issue/ticketi kohta oma feature-branch, mis aitab tagada, et korraga muudetav funktsionaalsus ei muutuks liiga suureks (keeruline testida, suurem konfliktide ja vigade oht, keerulisem tagantjärgi viga otsida ning muudatusi tagasi võtta).
Mergemine
Kui issue skoobiga funktsionaalsus on feature-branchis valmis ning testitud, on aeg hakata mergema kirjutatud koodi main või development branchi.
Mergemine on protsess, mille käigus lisatakse muudetud haru muudatused sihtharusse. Reeglina tuleb pärast feature branchi giti pushimist main branchi mergemise jaoks luua merge request, kus on enne päriselt koodi mergemist näha kõik muudatused ning saab määrata isiku (tiimikaaslase), kes vaataks tehtud muudatused üle ehk teeks code review.
Mitte ükski main branchi mergemine ei tohi toimuda ilma code review’ta!
Nii aktiivseid, juba mergetud kui ka closetud merge requeste näeb siit.
Avades selle, peaks code-review tegija käima muudatused üle ning veenduma koodi kvaliteedis: kas kood töötab nii nagu vaja, kas lahendus on mõistlik või saaks seda kuidagi paremaks teha. Kui
Siinkohal on oluline märkida, et vea tekkimisel laskub code review tegijale sama suur vastutus kui koodi kirjutajale!
Teinekord on kasulik see branch endale arvutisse pullida, et paremini navigeerida ja hallata terviklikku pilti ning mingi nähtava funktsionaalsuse puhul ka näiteks rakendus (antud projektis mäng) endal tööle panna ning ise läbi proovida NB! Chekoutides teise branchi peaks oma praeguse branchi aktiivsed (commitimata) muudatused commitima või shelvema, sest vastasel juhul need liiguvad kaasa.
Kui ülevaataja on veendunud, et uus implementeeritud kood on kvaliteetne ja töökorras, võib ta panna merge requestile approve. Vastasel juhul võib ta seal samas jätta reapõhiseid soovitusi või võtta ühendust tiimikaaslasega, kes korrektse tagasiside puhul need ära parandaks ning uuesti gitlabi pushiks (uut merge requesti selleks tegema ei pea, need näidatakse kohe pärast pushi ära seal samas).
Merge konfliktid
Merge requesti tehes võib git tuvastada merge konflikte.
See juhtub siis, kui mitmes eri branchis on muudetud sama koodi (näiteks teevad kaks isikut mõlemad oma feature branchid mainist samal ning esimene muutis oma branchis meetodit A ning merges selle ning teine muutis ka oma branchis samasid ridasid ning üritab samuti mergeda enne maini muudatuste endale mergemist) ning Git ei tea, milline on õige. Seetõttu tuleks need lahendada ehk resolveda näidates gitile, et milliseid muudatusi võtta.
