Aloittelijan yleisimmät virheet GitHubissa ja kuinka vältät ne

GitHubin käytössä ensimmäiset ongelmat syntyvät usein pienistä väärinkäsityksistä. Tiedosto on tallennettu, mutta muutos ei näy verkossa. Uusi ominaisuus päätyy väärään haaraan. Projektin mukana lähtee asetustiedosto, jota ei ollut tarkoitus jakaa.

Näitä tilanteita voi ehkäistä ymmärtämällä muutaman perusasian. Kaikkia Git-komentoja ei tarvitse osata ulkoa, mutta ennen tallentamista ja lähettämistä kannattaa tietää, missä projektissa työskentelee ja mitä muutoksia on tekemässä.

Tässä artikkelissa käydään läpi tavallisia aloittelijan virheitä ja käytännön tapoja välttää niitä. Esimerkkien tiedostonimet ja haarat vaihdetaan aina oman projektin mukaisiksi.

Git ja GitHub menevät sekaisin

Git on versionhallintajärjestelmä, joka toimii myös omalla tietokoneella ilman jatkuvaa verkkoyhteyttä. GitHub puolestaan tarjoaa Git-tietovarastoille verkkopalvelun sekä yhteistyötoimintoja.

Ero näkyy arkisessa työskentelyssä. Paikallinen commit tallentaa muutoksen Git-historiaan, mutta GitHubiin se siirtyy vasta lähettämällä. GitHubissa tehty muutos ei myöskään ilmesty automaattisesti tietokoneella olevaan kopioon.

Ajattele työskentelyä kahtena toisiinsa yhdistettynä paikkana:

• Tietokoneellasi muokkaat ja tallennat paikallista projektia.
• GitHubissa jaat tallennetut muutokset muiden kanssa.

Kun ymmärrät tämän eron, monet näennäisesti kadonneet muutokset löytyvät oikeasta paikasta. GitHubin Git-esittely.

Tiedoston tallentamista pidetään committina

Editorin tallennuspainike kirjoittaa muutoksen tiedostoon. Se ei vielä lisää muutosta Gitin historiaan.

Tavallinen tallennusketju etenee näin:

1. Muokkaa tiedostoa.
2. Tallenna se editorissa.
3. Valitse muutokset valmistelualueelle.
4. Tee commit.
5. Lähetä commit tarvittaessa GitHubiin.

Esimerkiksi README-tiedoston muutos voidaan tallentaa seuraavasti:

git add README.md
git commit -m "Täydennä asennusohjetta"

Jos haaran etäseuranta on jo määritetty, lähettäminen onnistuu tavallisesti komennolla git push.

Tarkista tilanne komennolla git status. Se auttaa erottamaan muokatut tiedostot ja seuraavaan committiin valitut muutokset. Puhdas työtila ei kuitenkaan yksin todista, että kaikki paikalliset commitit olisi lähetetty GitHubiin. Gitin peruskomennot.

Kaikki muutokset lisätään mukaan tarkistamatta

Komento git add . on kätevä, mutta se voi valita mukaan paljon enemmän kuin ajattelit. Projektikansioon on saattanut ilmestyä lokitiedostoja, kokeiluja tai paikallisia asetuksia.

Aloittelijalle hyvä tapa on nimetä lisättävät tiedostot:

git add README.md
git add style.css

Tarkista tämän jälkeen committiin valittu sisältö:

git diff --cached

Käy vertailu läpi rauhassa. Vastaako jokainen muutos tallennuksen tarkoitusta? Onko mukana vahingossa poistettua sisältöä tai testitekstiä?

Tarkistus kannattaa tehdä myös graafisessa Git-sovelluksessa. Muutoslistan valintaruudut eivät korvaa tiedostojen sisällön lukemista. Erityisesti automaattinen muotoilu voi muuttaa rivejä, joihin et tarkoittanut koskea.

Gitignore lisätään liian myöhään

.gitignore määrittelee tiedostoja ja kansioita, joita Gitin ei tavallisesti pidä ottaa uutena sisältönä seurantaan.

Projektista riippuen tiedosto voi sisältää esimerkiksi:

.env
node_modules/
*.log

Näitä sääntöjä ei pidä kopioida ymmärtämättä projektin tarpeita. Esimerkiksi kaikki asetustiedostot eivät ole salaisia, ja osa niistä kuuluu yhteiseen versionhallintaan.

Yleinen väärinkäsitys on, että .gitignore poistaisi jo seurattavan tiedoston automaattisesti versionhallinnasta. Näin ei tapahdu. Sääntö ei myöskään poista aikaisempiin committeihin tallennettua sisältöä.

Laadi ohitussäännöt ennen ensimmäistä laajaa tallennusta ja tarkista niiden toimivuus muutoslistasta. Gitin gitignore-ohje.

Salainen avain päätyy tietovarastoon

Rajapinta-avain, salasana tai yksityinen avaintiedosto voi päätyä GitHubiin vahingossa esimerkiksi asetustiedoston mukana. Yksityinenkään tietovarasto ei ole hyvä paikka tarpeettomille salaisuuksille.

Käytä dokumentaatiossa kuvitteellisia arvoja ja erota paikalliset tunnukset jaettavista esimerkkiasetuksista. Esimerkiksi .env.example voi esitellä tarvittavat muuttujat ilman oikeita avaimia.

Jos toimiva tunnus on jo julkaistu, ensimmäinen toimenpide on sen mitätöiminen tai vaihtaminen kyseisessä palvelussa. Pelkkä tiedoston poistaminen uusimmasta versiosta ei poista avainta historiasta.

Historian puhdistaminen on erillinen työ, joka voi vaikuttaa muiden projektikopioihin. Noudata siihen GitHubin ohjeita ja sovi tarvittavista toimista muiden osallistujien kanssa. GitHubin ohje arkaluonteisen sisällön poistamiseen.

Muutoksia tehdään väärässä haarassa

Kun avoinna on monta projektia tai työtehtävää, haaran tarkistaminen unohtuu helposti. Korjaus saattaa päätyä päähaaraan tai toisen ominaisuuden keskelle.

Aloita työ tarkistamalla:

git status
git branch --show-current

Luo tarvittaessa tehtävälle oma haara projektin sovitusta lähtökohdasta:

git switch -c korjaa-hakupainike

Haaran nimi kannattaa sitoa työn tarkoitukseen. korjaa-hakupainike kertoo enemmän kuin testi-uusi.

Tee erillisille muutoksille omat haaransa. Silloin yhden tehtävän keskeneräisyys ei vaikeuta toisen tarkastamista ja yhdistämistä. Tämä on myös GitHubin haaroihin perustuvan työnkulun keskeinen käytäntö. GitHub flow.

Yhteen committiin kerätään liian paljon

Päivän lopussa tehty suuri commit voi sisältää valikkokorjauksen, uuden kuvan, riippuvuuspäivityksen ja tekstimuutoksia. Myöhemmin on vaikea selvittää, mikä niistä aiheutti ongelman.

Jaa työ ymmärrettäviin kokonaisuuksiin. Yhden commitin pitäisi olla kuvattavissa lyhyellä, täsmällisellä lauseella.

Hyviä viestejä ovat esimerkiksi:

• Korjaa hakupainikkeen kohdistus.
• Lisää puuttuva asennusvaihe.
• Päivitä etusivun esittelykuva.

Samaan muutokseen liittyvät tiedostot voivat kuulua yhteen committiin. Tavoitteena ei ole tehdä mahdollisimman paljon tallennuksia, vaan muodostaa historia, jota pystyy lukemaan.

Kysy ennen tallentamista: ymmärtäisinkö tämän muutoksen tarkoituksen vielä puolen vuoden kuluttua?

Lähetysvirhe ratkaistaan pakottamalla

Git voi hylätä push-komennon, jos etähaarassa on muutoksia, joita paikallisesta historiasta puuttuu. Tämä voi tapahtua myös yksin työskennellessä, jos muokkaat tiedostoja sekä selaimessa että tietokoneella.

Tällainen non-fast-forward-virhe suojaa etähaaran historiaa ylikirjoittamiselta. Ennen uutta lähetystä muutokset pitää sovittaa yhteen. GitHubin lähetysvirheohje.

Älä lisää komentoon --force vain saadaksesi virheen katoamaan. Pakotettu lähetys voi korvata etähaaran historiaa ja hävittää siitä muiden committeja.

Myös --force-with-lease edellyttää ymmärrystä historian muuttamisesta. Sen lisätarkistus ei tee pakottamisesta yleistä korjauskeinoa. Gitin push-ohje.

Ristiriidassa hyväksytään oma versio lukematta

Yhdistämisristiriidassa editori voi tarjota vaihtoehtoja oman tai saapuvan muutoksen hyväksymiseen. Painikkeen valitseminen ratkaisee teknisen ristiriidan, mutta lopputulos voi silti olla väärä.

Lue molemmat muutokset ja selvitä niiden tarkoitus. Jos toinen kehittäjä korjasi saavutettavuutta ja sinä valikon toimintaa, lopullisen version pitäisi mahdollisesti sisältää molemmat parannukset.

Ristiriidan käsittelyssä kannattaa:

• Tarkastella ympäröivää koodia.
• Selvittää muutosten tausta.
• Muodostaa tarkoituksenmukainen lopputulos.
• Tarkistaa, ettei ristiriitamerkintöjä jäänyt tiedostoon.
• Kokeilla toiminta uudelleen.

Tarvittaessa kysy toiselta tekijältä. Lyhyt keskustelu on parempi kuin huomaamatta poistettu korjaus.

Pull request lähetetään ilman selitystä

Otsikko ”Päivityksiä” ja tyhjä kuvaus siirtävät selvitystyön tarkastajalle. Hän joutuu päättelemään tiedostoista, mitä tavoittelit.

Kirjoita muutosehdotukseen:

• Mikä ongelma ratkaistaan.
• Mitä toiminnassa muuttuu.
• Miten muutos tarkistettiin.
• Mitä olennaista on vielä kesken.

Tarkista myös kohdehaara ja tiedostovertailu. Jos mukana näkyy kymmeniä vieraita muutoksia, älä oleta niiden kuuluvan ehdotukseen.

Keskeneräisen työn voi merkitä luonnokseksi. Kun saat palautetta, tee korjaukset samaan haaraan ja päivitä ehdotusta uusilla commiteilla. GitHubin muutosehdotusten työnkulku.

Suuret tiedostot täyttävät historian

Videoiden, tietokantakopioiden ja toistuvien ZIP-pakettien tallentaminen Git-historiaan voi kasvattaa projektia nopeasti. Uusin tiedostoversio ei ole ainoa säilyvä sisältö, sillä myös aikaisemmat versiot voivat jäädä historiaan.

GitHub estää tavallisessa Git-tallennuksessa yli 100 MiB:n tiedostot. Selainlatauksissa raja on pienempi, 25 MiB tiedostoa kohti.

Arvioi, kuuluuko aineisto lähdekoodin yhteyteen. Suurille versionhallittaville tiedostoille voidaan käyttää Git LFS:ää, kun taas jaettavat ohjelmapaketit voivat sopia Releases-julkaisuihin. GitHubin suurten tiedostojen ohje.

Virhettä perutaan ymmärtämättä seurauksia

Verkosta löytynyt palautuskomento voi poistaa myös työtä, jonka halusit säilyttää. Erityisesti työtilaa ja historiaa muuttavien komentojen vaikutus kannattaa selvittää ennen suorittamista.

Jo jaetun tavallisen commitin kumoamiseen git revert on usein sopiva vaihtoehto. Se muodostaa uuden commitin, joka kumoaa valitun tallennuksen muutoksia. Se ei poista alkuperäistä committia historiasta. Myös revert voi vaatia ristiriitojen ratkaisemista. Gitin revert-ohje.

Pysähdy ongelmatilanteessa tarkistamaan työtila ja tavoite. Selvitä ensin, haluatko perua tallentamattoman muokkauksen, paikallisen commitin vai jo jaetun muutoksen. Oikea toimintatapa riippuu tästä erosta.