Mikä GitHub on ja mihin sitä voi käyttää? Näin rakensin Liida do Labin

GitHub kuulosti mulle pitkään työkalulta, joka kuuluu lähinnä ohjelmistokehittäjille. Sitten aloin rakentaa Liida do Labia.

Halusin tehdä oman paikan pienille digitaalisille työkaluille, kokeiluille ja asioille, joita haluan opetella rakentamaan itse. Siinä vaiheessa vastaan tuli nopeasti myös GitHub.

Tässä artikkelissa avaan GitHubia sen kautta, miten olen itse käyttänyt sitä Liida do Labin rakentamisessa.

Samalla käydään läpi, mitä eroa on VS Codella, Next.js:llä, GitHubilla, hostingilla ja domainilla. Nämä menivät ainakin omassa päässäni alkuun helposti yhdeksi isoksi tekniseksi möykyksi.

‍

Mikä GitHub on?

Yksinkertaistettuna GitHub on paikka, jossa voidaan säilyttää ja hallita ohjelmistoprojektin koodia. Liida do Labilla on GitHubissa oma repository eli repo.

Repo sisältää projektin tiedostot ja pitää samalla kirjaa siitä, miten projekti muuttuu. Tämä on yksi GitHubin tärkeimmistä hyödyistä. Sen sijaan, että tietokoneellani olisi kansiot:

• lab-uusi
• lab-uusi2
• lab-final
• lab-final-oikeasti-final

GitHubissa projektilla on hallittu muutoshistoria.

‍

Mitä VS Code sitten tekee?

VS Code eli Visual Studio Code on ohjelma, jossa teen itse varsinaista rakentamista. Avaan siellä Labin projektin, näen tiedostot ja muokkaan koodia.

Olen käyttänyt VS Codessa apuna myös tekoälyä ja koodausavustajia. Se on ollut mulle hyvä tapa opetella samalla, kun teen. Kaikkea ei tarvitse osata ulkoa ennen kuin aloittaa.

Mutta on hyödyllistä ymmärtää, mitä eri osat tekevät.

‍

Entä Next.js?

Liida do Lab on rakennettu Next.js:llä. Next.js ei ole sama asia kuin VS Code eikä GitHub.

Se on framework eli kehys, jonka päälle verkkosovellus rakennetaan. Hyvin yksinkertaistettuna:

• VS Code on työväline, jossa kirjoitan koodia.
• Next.js on teknologia, jolla sovellus on rakennettu.
• GitHub säilyttää projektin ja sen versiot.

Näiden lisäksi tarvitaan vielä paikka, jossa valmis sovellus ajetaan verkossa.

‍

Miten VS Code ja GitHub liittyvät toisiinsa?

Kun teen Labissa muutoksen VS Codessa, voin tallentaa muutoksen GitHubiin. Tässä vastaan tulevat sanat commit ja push.

Commit tarkoittaa käytännössä projektin muutoksen tallentamista versionhallintaan. Sen yhteydessä voidaan kirjoittaa esimerkiksi:

Lisätty uusi työkalu Labin etusivulle

Push puolestaan vie nämä paikallisesti tehdyt muutokset GitHubiin. Näin GitHubissa oleva projekti pysyy ajan tasalla.

‍

Julkaiseeko GitHub sovelluksen verkkoon?

Tämä on kohta, joka on helppo ymmärtää väärin. Ei välttämättä.

Se, että Next.js-projektin koodi on GitHubissa, ei yksin tarkoita, että GitHub ajaisi sovelluksen osoitteessa lab.liidado.com.

GitHubin tehtävä tässä kokonaisuudessa on ennen kaikkea koodin ja sen versioiden hallinta. Next.js-sovellus tarvitsee lisäksi ympäristön, jossa se rakennetaan ja ajetaan verkossa.

Tähän voidaan käyttää erilaisia hosting- ja deployment-palveluita. Yksi Next.js-projekteissa yleisesti käytetty vaihtoehto on Vercel.

Mitä Vercel sitten tekisi?

Jos GitHub-projekti yhdistetään Verceliin, roolit menevät yksinkertaistettuna näin:

• VS Code → kirjoitan koodin
• Next.js → sovellus on rakennettu tällä teknologialla
• GitHub → säilyttää projektin ja sen versiot
• Vercel → rakentaa ja julkaisee sovelluksen verkkoon
• Domain → antaa sovellukselle esimerkiksi osoitteen lab.liidado.com

Vercelin hyöty on myös se, että julkaiseminen voidaan automatisoida.

Kun GitHubiin viedään uusi versio projektista, Vercel voi huomata muutoksen ja julkaista päivitetyn version automaattisesti. Tätä kokonaisuutta kutsutaan deploymentiksi.

‍

Entä lab.liidado.com?

lab.liidado.com on alidomain eli liidado.com-domainin alle tehty osoite.

Mun domainin DNS-tietueita hallitaan Namecheapissa. DNS:n tehtävä ei kuitenkaan ole rakentaa tai ajaa Labia. DNS kertoo käytännössä selaimelle:

“Kun joku kirjoittaa lab.liidado.com, mene tähän palveluun.”

Siellä toisessa päässä täytyy siis olla palvelu, joka oikeasti hostaa sovellusta. Tämä ero domainin, DNS:n ja hostingin välillä on yksi niistä asioista, jotka ovat alkaneet hahmottua mulle paremmin vasta itse tekemällä.

‍

GitHub ei siis ole sama asia kuin verkkohotelli

Tämä on ehkä tärkein asia, jonka itse nostaisin GitHubista esiin aloittelijalle. GitHubissa voi olla koko sovelluksen lähdekoodi. Mutta verkkosivun osoite, DNS, palvelin ja itse sovelluksen ajaminen ovat eri asioita.

GitHub on yksi pala kokonaisuudessa. Ja juuri tämän vuoksi GitHubia on ehkä helpompi ymmärtää oikean projektin kautta kuin lukemalla listaa sen ominaisuuksista.

‍

Miksi käytän GitHubia Liida do Labissa?

Mulle olennaisin syy ei ole se, että “koodiprojekteissa kuuluu käyttää GitHubia”. 

Haluan Labista projektin, jota voin kehittää pitkään. Sinne voi tulla uusia työkaluja ja kokeiluja, ja projektin rakenne muuttuu jatkuvasti. Silloin versionhallinnasta on oikeasti hyötyä.

Lisäksi GitHub mahdollistaa sen, että projektin voi yhdistää muihin palveluihin ja automatisoida esimerkiksi julkaisemista.

‍

GitHubin muutama tärkeä termi

Jos GitHub on uusi, alkuun ei tarvitse ymmärtää kaikkea. Mulle olennaisimmat käsitteet ovat olleet nämä:

• Repository eli repo = projektin paikka GitHubissa.
• Commit = tallennettu muutos projektissa.
• Push = muutosten vieminen omalta koneelta GitHubiin.
• Branch = projektin rinnakkainen versio, jossa voi tehdä muutoksia rikkomatta suoraan pääversiota.

Jo näiden ymmärtäminen tekee GitHubista huomattavasti vähemmän mystisen.

‍

Entä GitHub Copilot?

GitHub ja GitHub Copilot eivät ole sama asia. GitHub on alusta projektien ja koodin hallintaan. GitHub Copilot taas on tekoälyä hyödyntävä koodausavustaja, jota voidaan käyttää esimerkiksi VS Codessa.

Olen itse käyttänyt tekoälyä koodaamisen apuna erityisesti uuden oppimisessa, virheiden selvittämisessä ja ratkaisujen löytämisessä. Tästä aiheesta riittää asiaa omaan artikkeliinsa. En avaa sitä tässä sen tarkemmin.

‍

Kaikkea ei tarvitse osata ennen kuin aloittaa

Liida do Lab on mulle myös tapa opetella. En aloittanut projektia siksi, että hallitsisin valmiiksi täydellisesti GitHubin, Next.js:n tai kaikkia niiden ympärillä olevia työkaluja.

Olen opetellut niitä sitä mukaa, kun olen tarvinnut niitä johonkin oikeaan ongelmaan. Ja ehkä juuri siksi tämä tapa sopii mulle.

Ensin on asia, jonka haluan tehdä. Sitten selvitän, millä se kannattaa toteuttaa. GitHub on yksi niistä työkaluista, jotka alkoivat tuntua paljon loogisemmilta vasta siinä vaiheessa, kun sille oli oikea käyttötarkoitus.

‍

‍