Versiohallinnoinnista (versionhallinta) on tullut tärkeä osa ohjelmistojen kehittämisprosessia. Versiohallinta auttaa tallentamaan projektiin ajan mittaan tehdyt muutokset, jotta tietyt versiot voidaan palauttaa mieleen myöhemmin. Puhun GitHubista.

Kun aloitin kehittäjänä, aloin käyttää GitHubia, koska kaikki sanoivat, että kehittäjien on välttämätöntä pitää koodinsa verkossa. Tätä ajatellen pidin sitä paikkana, johon voin tallentaa kaikki projektini, jotta voisin ladata ne takaisin, jos järjestelmäni kaatuu.

Hauskaa, eikö?

Myöhemmin tajusin, että GitHub oli enemmän kuin vain se, se on paikka, jossa voin tarkastella kaikkea edistymistä, jota olen tehnyt jokaisessa projektini tai ohjelmani rakentamisen vaiheessa. Se sattuu olemaan myös paikka, jossa kaikki ympäri maailmaa voivat osallistua projekteihin erilaisilla ideoilla.

Vuoden puolivälin tienoilla, kun aloitin Microverse-yrityksessä, minulle esiteltiin GitHub Flow. GitHub Flow kannustaa sinua luomaan ominaisuushaaroja jokaiselle ohjelmistosi ominaisuudelle. Kun uskot, että ohjelmistosi tai projektisi on valmis katsottavaksi tai käytettäväksi, luot pull requestin ja yhdistät sen master-haaraan.

Cool eikö?

clone the project

paikalliseen arkistoosi.

cd

arkistoon

tarkista haara, jossa olet tällä hetkellä

.

Mene etähaarasi repositoryyn GitHubissa ja luo pull request ja yhdistä, kun uskot ominaisuuden olevan valmis

Siten pääset näkemään kaikki luodut ominaisuudet ja mitä lisäsit kussakin vaiheessa. Kun etenin, tajusin, että master-haara oli pääasiassa tuotantoa varten ja sillä hetkellä, kun yhdistät pull requestin, sanot, että kyseinen ominaisuus on valmis kaikkien käytettäväksi tai katsottavaksi.

Tällöin tulin siihen tietoon, että GitHub flow toimii täydellisesti pienissä projekteissa, mutta entä jos minulla on projekti, jossa on useampi kuin yksi tärkeä ominaisuus ja käytän GitHub flowta, sanon epäsuorasti, että kaikki ominaisuudet, jotka yhdistetään master-haaraan, ovat valmiita tuotantoon, mutta jos ajattelemme sitä, ovatko ne?

Yhden ominaisuuden julkaiseminen projektille, jossa on monta ominaisuutta, ei ole järkevää, ja tässä kohtaa Git Flow tulee kuvaan. Se on hyvin samankaltainen kuin GitHubin Flow, mutta esittelee paremman tavan työskennellä versionhallinnan kanssa.

Git Flow’ssa luomme kehityshaaran ja teemme kehityshaarasta oletushaaran, kunnes olemme valmiita tuotantoon. Näin kaikki ominaisuushaarat luodaan kehityshaarasta ja yhdistetään kehityshaaraan, kun ne valmistuvat.

Se käy järkeen, eikö? Nyt pääsen yhdistämään master-haaraan vasta, kun uskon ohjelmani olevan valmis tuotantoon kaikkine lisättyine ominaisuuksineen.

Kloonattuasi arkistosi luo

development

haara

Tarkista, millä haaralla työskentelet tällä hetkellä

Kokeile lisätä tiedosto, ehkä HTML-tiedosto niin, että pystyt päivittämään etähaaran arkistosi kehityshaaran kanssa.

Mene etävarastoosi GitHubissa , siirry asetuksiin, klikkaa haarat ja tee kehitys oletushaaraksi

Nyt, voit luoda feature-haaroja

development

-haarasta, luoda siitä pull requestin ja yhdistää

development

-haaraan.

Kun kaikki ominaisuutesi ovat valmiina, noudata samoja edellä mainittuja vaiheita, tee masterista jälleen oletusarvo, luo pull request kehityksestä masteriin ja yhdistä tuotantoa varten.

Tiedän, että tämä on ollut pitkä luku, mutta luotan siihen, että nyt meidän pitäisi tietää, milloin kannattaa käyttää GitHub flowta tai Git Flowta.

Kiitos lukemisesta.

Tags