Git versiohallinta

• gitlab-palveluun rekisteröityminen

  • kirjaudu sisään henkilökohtaisella yliopistotunnuksellasi: https://gitlab.jyu.fi

• git-asiakasohjelman asentaminen

  • tarviiko asiakasohjelmaa asentaa, jos käyttää suoraan Visual Studiosta?
  • saako harkkatyön suunnitelman tehtyä myös Visual Studiosta?

• commit, push, pull

• gitignore-tiedostojen käyttäminen

  • voidaanko opiskelijoille tarjota valmis template?
    • Githubissa on valmiiksi valittavissa "VisualStudio" .gitignore-tiedosto
      • Sisältää paljon ylimääräistä kurssin kannalta, mutta toimii hyvin.
  • Voiko jopa gitlabiin tehdä projektimallin jossa olisi valmis gitignore (tämä onnistuu joissain muissa git-palveluissa)
    • Voi, erittäin helposti: https://gitlab.com/gitlab-org/project-templates/contributing
      • Halutaanko projektimalliin mitään muuta kuin .gitignore?

• erikoistilanteita:

  • kansion nimen muuttuminen (esim. jos pelin nimeä muutetaan)
  • ...

1. Vuoden 2022 projekti-sivut

• https://gitlab.jyu.fi/tie/ohj1
• https://gitlab.jyu.fi/tie/ohj2

Ohj1

Tämä luku on työn alla.

1. Aloita tekemällä remote repository pohjaprojektista, eli fork

Fork on projektista tehtävä itsenäinen "haara", joka jatkaa omaa elämäänsä, mutta josta on viite alkuperäiseen projektiin ja alkuperäisestä voi seurata mitä "forkkeja" siitä on tehty. Forkin ansiosta saadaan uuteen projektiin samat alkuasetukset.

1. Kirjaannu gitlabiin https://gitlab.jyu.fi/ JY:n tunnuksilla

   • jos sinulla ei ole JY:n tunnuksia, niin voit käyttää https://gitlab.com tai https://github.com joihin voit tehdä itse tunnukset

2. Mene gitlabin Ohj1-pohjaan: TODO: Toimiva linkki

   • jos haluat käyttää gitlab.com, niin forkattava osoite on:
     TODO: Toimiva linkki
   • jos haluat tehdä GitHubissa, niin forkattava osoite on:
     TODO: Toimiva linkki

3. Valitse oikeasta ylänurkasta fork

4. Jos tulee valittavaksi useampia namespaceja (ryhmiä), valitse omaa tunnustasi vastaava.

5. Hetken päästä aukeaa uusi sivu. Ota sen vasemmasta reunasta Settings.

6. Jos teet ryhmässä, niin lisää vielä Members/Invite member-kohdasta muiden ryhmäläisten käyttäjätunnukset ja vastaavasti oikeuksiksi Maintainer. Ryhmäläisten pitää olla ensin kirjaantunut ainakin kerran gitlabiin.

7. Ota Settings/General/Visibility, project features, permissions ja tarkista että projektilla on julkinen näkyvyys.

8. Projektisi remote repository on nyt 
   https://gitlab.jyu.fi/Anonymous/ohj1.git

   Käytä tätä nimeä tulevissa ohjeissa. Muista lisätä tämä polku projektisi suunnitelmaan, niin ohjaajat löytävät sen.

9. Jatka tekemällä tästä lokaali klooni (local repository) koneeseesi: clone

2. Gitin commitit ja viitteet

Tässä luvussa pyritään kuvaamaan hieman enemmän Gitin sisäistä toimintaa.

Kukin commit on "kopio sen hetkisestä työhakemiston sisällöstä". Tai tarkemmin stagessa (index) commitointi hetkellä oleesta sisällöstä. Commitissa syntyy tiedostoista kopiot .git/objects hakemistoon. Itse commitit sisältävät viitteitä näihin kopioihin. Jokaisesta commitista on myös viite edelliseen committiin. Rinnakkaisten haarojen yhdistämisen jälkeen taakseviitteitä voi olla useampiakin.

Komennot switch (uudemmissa Giteissä) tai checkout siirtävät tietyn commitin sisällön työhakemistoon.

Seuraavissa kuvissa on vihreillä laatikoilla merkitty committeja (nimetty c1, c2 ja c3) ja soikeilla laatikoilla nimettyjä viitteitä. Kuvissa ei pyritä kuvaamaan kopioitujen tiedostojen sisältöjä, vaan kukin commit ajatellaan, että se tavalla tai toisella sisältää tiedot kopioiduista tiedostoista.

"Mystiset" kirjainsarjat laatikoissa kuvaavat committia vastaavan hash-arvon alkuosaa. Näitä hash-arvoja voit katsoa esim kutsulla:

git log

tai ehkä vielä paremmin näkee missä HEAD ja haarat ovat:

git log --graph --abbrev-commit --decorate 

Hash-arvot tulevat, kun lasketaan sha1-hash -arvo committiin liittyvistä identifioivista tekijöistä (mm. sisältö, tekoaika ja tekijä).

2.1 commit

Esimerkiksi kahden commitin jälkeen local repository (.git-hakemisto) voisi olla loogisesti alla olevan näköinen.

3. Tiedostojen vieminen lokaaliin repositoryyn (commit)

Kun halutut tiedostot ovat index/stage-alueella, siirretään ne sieltä lokaaliin repositoryyn:

git commit -m "kuvaava viesti miksi muutokset on tehty"

Commit tekee työhakemiston lisättäväksi merkityistä tiedostoista "pikakuvan" (snapshot). Loogisesi commit on siis tavallaan kopio työhakemiston sisällöstä, tekijästä ja muutosvististä tiettynä ajanhetkenä. Oikeasti se ei ole täysi kopio, koska kaikki tiedostot eivät muutu commitissa, vaan joukko viitteitä .git/objectshakemiston tiedostoihin. Commitit muodostavat suunnatun verkon, josta päästään tarvittaessa mihin tahansa committiin joka on tehty.

• Git-ohje: commit, reference: commit

4. Push

Ohj2

Uudet Ohj2 ohjeet Gitin käytöstä:

• https://tim.jyu.fi/view/kurssit/tie/ohj2/tyokalut/git/ohj2git
• https://tim.jyu.fi/view/kurssit/tie/ohj2/tyokalut/git/gitjakomentorivi

Ensin asennetaan git tuolta https://git-scm.com/download/win

git bash ikkunassa:

git clone https://gitlab.jyu.fi/tie/ohj2/k2019/vesal.git
git add files.txt
git add kuvat
git status
git commit
git push

Jos ei ole määritelly editoria, niin commiteissa yms aukeaa VIM, jossa muokkauksen jälkeen pääsee pois

[ESC] :wq[ENTER]

Eli voisiko prosessi olla seuraava karkeasti:

1. tehdään master, jossa on työn 1. vaihe
2. kun siirrytään 2. vaiheeseen, tehdään tuosta branch1 (nimelle vaihe1)
3. N=2
4. tehdään masterista branchN (nimelle vaiheN)
5. työstetään branchN kunnes se on näyttökunnossa.
6. mergetään branchN masteriin
7. jos N<7, niin N++ ja jatketaan kohdasta 4.

Silloin kukin HT vaihe jää näkyviin branchN ja master on aina se mitä esitellään.

1. vaihe menisi eri tavalla, koska silloin 1. viikolla (jolloin HT1 pitää ola valmis) ei tarvitse vielä ymmärtää mergeistä ja brancheistä.

Ohj1 tehtäisiin koko ajan masterissa yksinkertaisuuden vuoksi.