GitHubin yleisimmät termit selitettynä suomeksi

Tiivistelmä

GitHubin käyttöliittymässä vastaan tulevat repository, commit, branch ja pull request voivat näyttää aluksi vaikealta ammattikieleltä. Niiden taustalla on kuitenkin käytännöllisiä asioita: projektin säilyttäminen…

Englanninkielisiä termejä kannattaa opetella myös sellaisinaan, koska ne näkyvät painikkeissa, ohjeissa ja kehittäjien keskusteluissa. Suomenkielinen selitys auttaa ymmärtämään, mitä toiminto tekee ja missä tilanteessa sitä tarvitaan.

Tässä artikkelissa käsitteitä havainnollistetaan verkkosivuprojektilla. Samat periaatteet toimivat myös sovellusten, dokumentaation ja muiden tiedostoista koostuvien kokonaisuuksien parissa.

Git ja GitHub – versionhallinta ja yhteistyöpalvelu

Git on versionhallintajärjestelmä, joka seuraa tiedostoihin tehtyjä muutoksia. Sen avulla voidaan tutkia projektin historiaa, vertailla aikaisempia toteutuksia ja selvittää, milloin jokin muutos tehtiin.

GitHub puolestaan on verkkopalvelu, jossa Gitillä hallittavia projekteja voidaan säilyttää ja kehittää yhdessä. Se tarjoaa esimerkiksi keskustelut, muutosehdotusten tarkastamisen ja tehtävien seurannan.

Jos muokkaat verkkosivun valikkoa omalla tietokoneellasi, Git voi tallentaa työn eri vaiheet. GitHubissa toinen kehittäjä voi tarkastella muutoksia ja kommentoida niiden toteutusta.

Gitin käyttäminen ei edellytä GitHubia. Paikallinen versionhallinta toimii myös ilman verkkoyhteyttä, mutta muutosten lähettäminen verkkopalveluun tarvitsee yhteyden. GitHubin esittely.

Repository eli projektin tietovarasto

Repository tarkoittaa tietovarastoa, josta käytetään usein lyhennettä repo. Se sisältää projektin tiedostot ja Gitin tallentaman muutoshistorian.

Verkkosivuston repossa voi olla esimerkiksi:

Sivupohjia ja tyylitiedostoja.
Kuvia ja muita käyttöliittymän aineistoja.
Asennusohjeita.
Automaattisia testejä.
Projektin asetustiedostoja.

GitHubissa repositoryyn liittyy myös yhteistyötä tukevia toimintoja, kuten tehtäviä ja muutosehdotuksia.

Public repository on julkinen tietovarasto, jonka sisältöä muut voivat katsella. Private repository on yksityinen, ja sen käyttö edellyttää asianmukaisia oikeuksia. Julkinen näkyvyys ei itsessään määritä koodin käyttöehtoja: niitä varten tarkastetaan projektin lisenssi.

Repositorya voi ajatella projektin kotina. Sieltä löytyvät sekä työn nykyinen sisältö että tieto siitä, miten siihen on päädytty. GitHubin sanasto.

README ja Markdown – projektin esittely ja tekstin muotoilu

README on projektin opastiedosto. GitHub näyttää sen yleensä tietovaraston etusivulla, joten se on luonteva ensimmäinen lukukohde uuteen projektiin tutustuvalle.

Hyvä README vastaa käytännön kysymyksiin:

Mitä projekti tekee?
Miten sen saa käyttöön?
Millaisia vaatimuksia asentamiseen liittyy?
Mistä löytyy lisäohjeita?
Miten kehitykseen voi osallistua?

Tiedoston nimi on usein README.md. Päätteen tarkoittama Markdown on tekstin merkintätapa, jolla muodostetaan esimerkiksi otsikoita, linkkejä ja listoja.

Verkkosivuteeman README voisi kertoa, kuinka teema asennetaan ja mistä sen asetukset löytyvät. Selkeä ohjeistus säästää käyttäjän aikaa, koska hänen ei tarvitse päätellä toimintatapaa lähdekoodista. GitHubin README-ohje.

Commit ja staging area – muutosten tallentaminen historiaan

Commit on versionhallintaan tehty tallennus, joka kuvaa projektin tilan kyseisessä vaiheessa. Siihen liittyy viesti, jonka avulla muutoksen tarkoitus voidaan ymmärtää myöhemmin.

Esimerkiksi ”Korjaa mobiilivalikon avautuminen” kertoo enemmän kuin ”Päivityksiä”. Hyvä tallennus käsittelee mielellään yhtä ymmärrettävää asiaa, jotta sitä on helppo tarkastella.

Staging area tarkoittaa valmistelualuetta. Sinne valitaan muutokset, jotka halutaan sisällyttää seuraavaan commitiin. Kaikkea keskeneräistä työtä ei siis tarvitse tallentaa samaan kokonaisuuteen.

Oletetaan, että korjaat valikon toiminnan ja kokeilet samalla otsikon uutta väriä. Voit valita valikkokorjauksen valmistelualueelle ja jättää värikokeilun odottamaan.

Tavallinen tiedoston tallentaminen editorissa ei vielä muodosta committia. Commit ei myöskään automaattisesti siirry GitHubiin, vaan lähettäminen on erillinen vaihe. Gitin käyttöopas.

Branch ja main – rinnakkainen kehityshaara

Branch tarkoittaa kehityshaaraa. Sen avulla ominaisuutta tai korjausta voidaan työstää erillään projektin toisesta kehityslinjasta.

Päähaaran nimi on monissa projekteissa main, mutta nimi voi olla muukin. Päähaaraan liittyvät käytännöt riippuvat projektista: sen ei pidä automaattisesti olettaa vastaavan tuotannossa olevaa versiota.

Uutta yhteydenottolomaketta varten voisi luoda haaran nimeltä yhteydenottolomake. Siinä lomakkeen rakennetta, ulkoasua ja toimintaa voidaan kehittää vaiheittain.

Kuvaava haaran nimi auttaa tunnistamaan työn tarkoituksen. Esimerkiksi korjaa-hakunappi kertoo sisällöstä enemmän kuin testi2.

Haara kuuluu samaan tietovarastoon. Se ei tarkoita, että koko projektille pitäisi perustaa erillinen GitHub-repository. Gitin sanasto.

Clone ja fork – kaksi erilaista kopiointitapaa

Clone tarkoittaa tietovaraston kloonaamista, tavallisesti omalle tietokoneelle. Näin saat projektista paikallisen Git-kopion, jota voit käsitellä omilla kehitystyökaluillasi.

Fork puolestaan muodostaa GitHubiin oman tietovaraston toisen projektin pohjalta. Se on hyödyllinen esimerkiksi silloin, kun haluat ehdottaa parannusta projektiin, jonka alkuperäiseen tietovarastoon sinulla ei ole kirjoitusoikeutta.

Eron voi muistaa näin:

Clone tuo projektin paikallista työskentelyä varten.
Fork antaa GitHubiin oman rinnakkaisen tietovaraston.

Näitä voidaan käyttää peräkkäin. Ensin teet projektista forkin, minkä jälkeen kloonaat oman forkisi tietokoneelle.

Pelkkä ZIP-paketin lataaminen tarjoaa tiedostot, mutta ei samanlaista Git-historialla varustettua työskentelykopiota kuin kloonaaminen. GitHubin sanasto ja forkien käyttöohje.

Remote, push, fetch ja pull – yhteys etätietovarastoon

Remote tarkoittaa paikalliseen projektiin määriteltyä etätietovarastoyhteyttä. Sen osoite voi viitata esimerkiksi GitHubissa sijaitsevaan repositoryyn. Tavallinen yhteyden nimi on origin.

Push lähettää paikallisia committeja etätietovarastoon. Sen avulla omalla tietokoneella tallennettu työ saadaan muiden saataville. GitHubin sanasto.

Fetch hakee etätietovaraston muutostietoja ja tarvittavaa sisältöä päivittämättä nykyisen työhaarasi tiedostoja suoraan. Se sopii tilanteeseen, jossa haluat ensin tarkastella muiden tekemää työtä. Gitin fetch-ohje.

Pull hakee muutokset ja sovittaa ne nykyiseen haaraan. Sovittamistapa riippuu asetuksista ja käytetyistä valinnoista: se voi tapahtua esimerkiksi yhdistämällä tai rebasen avulla.

Jos toinen kehittäjä on korjannut sivuston alatunnistetta, pull auttaa tuomaan työn omaan haaraasi. Mahdolliset ristiriidat voivat kuitenkin vaatia ratkaisemista ennen jatkamista. Gitin pull-ohje.

Pull request, review ja merge – ehdotuksesta yhteiseen koodiin

Pull request, lyhyesti PR, on ehdotus muutosten yhdistämisestä kohdehaaraan. Siinä voidaan esitellä työn tarkoitus, tarkastella tiedostoeroja ja keskustella toteutuksesta.

Review tarkoittaa muutosehdotuksen tarkastusta. Tarkastaja voi esimerkiksi hyväksyä työn, kommentoida yksityiskohtia tai pyytää korjauksia.

Merge tarkoittaa haarojen muutosten yhdistämistä. Kun lomakeominaisuus on valmis ja tarkastettu, sen muutokset voidaan yhdistää päähaaraan.

Hyödyllinen PR-kuvaus kertoo:

Minkä ongelman muutos ratkaisee.
Mitä käyttäjän näkökulmasta muuttuu.
Miten toimintaa on kokeiltu.
Liittyykö toteutukseen huomioitavia rajoituksia.

Pull requestin avaaminen ei itsessään yhdistä muutoksia. Se aloittaa ehdotuksen käsittelyn, ja yhdistäminen tehdään projektin käytäntöjen mukaisesti. GitHubin pull request -ohje.

Diff ja merge conflict – muutosten vertailu ja ristiriidat

Diff näyttää kahden version väliset erot. Sen avulla voi nähdä lisätyt ja poistetut rivit sekä tarkistaa, vastaako toteutus suunniteltua muutosta.

Merge conflict tarkoittaa yhdistämisristiriitaa. Se syntyy, kun Git ei pysty ratkaisemaan muutosten yhteensovittamista automaattisesti.

Näin voi käydä esimerkiksi silloin, kun kaksi kehittäjää muuttaa saman otsikon eri muotoon. Ihmisen täytyy päättää, mikä teksti lopputulokseen kuuluu.

Ristiriidan ratkaiseminen voi tarkoittaa kummankin muutoksen yhdistämistä uudeksi toteutukseksi. Sen jälkeen toiminta tarkistetaan, koska teknisesti onnistunut yhdistäminen ei yksin takaa ohjelman oikeaa käyttäytymistä. Gitin sanasto.

Issue, label ja milestone – tehtävien järjestäminen

Issue on seurattava asia, kuten virheilmoitus, kehitysehdotus tai tehtävä. Se antaa työlle oman keskustelupaikan.

Hyvä virheilmoitus kuvaa tapahtuneen, odotetun toiminnan ja vaiheet, joilla ongelman voi toistaa. Pelkkä ”valikko ei toimi” jättää selvittäjälle paljon arvattavaa.

Label on luokittelutunniste. Esimerkiksi bug, documentation ja enhancement auttavat ryhmittelemään sisältöä.

Milestone eli välitavoite kokoaa tehtäviä yhteisen päämäärän ympärille. Sellainen voisi olla verkkosivuston seuraavan version julkaisu.

Assignee puolestaan kertoo tehtävään nimetyn vastuuhenkilön. Näin keskustelusta käy ilmi, kuka asiaa edistää. GitHubin Issues-ohje.

Tag ja release – version merkitseminen ja julkaiseminen

Tag on nimetty viittaus Git-historian tiettyyn kohtaan. Esimerkiksi v1.2.0 voi merkitä julkaistun version lähdekoodin.

Release on GitHubissa muodostettava julkaisu, joka perustuu tagiin. Siihen voidaan liittää julkaisutiedot ja ladattavia tiedostoja.

Käyttäjälle release on usein sopiva paikka etsiä ohjelman asennuspakettia. Kehittäjälle tag tarjoaa täsmällisen viittauksen julkaisuun liittyvään koodiin.

Julkaisutiedoissa kannattaa kertoa uusista ominaisuuksista, korjauksista ja päivityksessä huomioitavista muutoksista. Pelkkä versionumero ei vielä selitä, miksi päivitys on hyödyllinen. GitHubin julkaisuohje.

GitHub Actions ja workflow – toistuvien töiden automatisointi

GitHub Actions suorittaa ennalta määriteltyjä tehtäviä. Workflow tarkoittaa työnkulkua, joka voi käynnistyä esimerkiksi muutosehdotuksen avaamisesta tai koodin lähettämisestä.

Työnkulku voi:

Tarkistaa koodin laatua.
Suorittaa automaattisia testejä.
Rakentaa ladattavan ohjelmapaketin.
Julkaista sivuston palvelimelle.

Job tarkoittaa työnkulun tehtäväkokonaisuutta ja step sen yksittäistä vaihetta. Runner on ympäristö, jossa tehtävät suoritetaan.

Vihreä tarkistusmerkki kertoo määritellyn tarkistuksen onnistumisesta. Sen merkitys riippuu siitä, mitä työnkulku todella tarkistaa.

Omassa harjoitusprojektissa voit kokeilla kokonaisuutta pienellä tekstikorjauksella: luo haara, tee commit ja avaa pull request. Silloin sanaston käsitteet yhdistyvät konkreettiseksi työskentelytavaksi. GitHub Actionsin perusteet.

Liittyvät kategoriat

Artikkeleita 2 020 artikkelia Github 12 artikkelia IT 1 946 artikkelia Pilvipalvelut 137 artikkelia