⚠️ Viikon tehtävien palautuksen deadline on tiistai 5.11. klo 23:59. Tehtävät on tarkoitus tehdä joko pajassa tai omatoimisesti.

Tehtävät palautetaan GitHubin avulla Labtooliin rekisteröimääsi repositorioon. Muista pushata tehtävät GitHubiin ennen palautuksen deadlinea! Klo 00 jälkeen tulevia repositorion päivityksiä ei huomioida pisteytyksessä, eli ne tuovat 0 pistettä.

Palautuksesta saadut pisteet ja palaute löytyy Labtoolista viimeistään deadlinea vastaavan viikon loppuun mennessä. Muista tarkistaa saamasi pisteet ja palaute. Jos pisteytyksestä herää kysymyksiä, lähetä viesti Labtoolin kautta.

Tämän viikon tehtävien palautuksesta on tarjolla 1 piste.

Kurssista

Kurssin nimi on muuttunut syksyllä 2023: vanha nimi oli Ohjelmistotekniikka. Kurssin oppimistavoitteet ovat edelleen suunnilleen samat kuin aiemmin. Kurssin suoritettuaan opiskelija

  • Tuntee ohjelmistotuotantoprosessin vaiheet
  • On tietoinen vesiputousmallin ja ketterän ohjelmistotuotannon luonteesta
  • Osaa soveltaa versionhallintaa osana ohjelmistokehitystä
  • Osaa soveltaa UML-mallinnustekniikkaa vaatimusmäärittelyssä ja ohjelmiston suunnittelussa tarkoituksenmukaisella tavalla
  • Tuntee ohjelmiston testauksen eri vaiheet
  • Osaa soveltaa automatisoitua testausta yksinkertaisissa ohjelmistoprojekteissa
  • Tuntee tärkeimpiä ohjelmiston suunnitteluperiaatteita ja osaa soveltaa niitä yksinkertaisissa projekteissa

Kurssin esitietoina ovat kurssit Tietokone työvälineenä, Ohjelmoinnin jatkokurssi, Tietokantojen perusteet sekä Tietokannat ja web-ohjelmointi. Oletuksena on, että näistä kaikista on käyty suhteellisen tuore versio ja että opittu on vielä hyvin mielessä.

Kurssin ensimmäisen kolmen viikon aikana harjoitellaan yksikkötestausta ja UML-kaavioiden tekemistä. Myös komentorivistä ja versionhallinnasta on tehtäviä, mutta nämä ovat syksystä 2023 alkaen vapaaehtoisia muuttuneiden esitietovaatimusten takia. Toisesta viikosta alkaen aloitetaan oman harjoitustyön tekeminen. Harjoitustyön tekemisen ohessa osoitetaan riittävä osaaminen kurssin oppimistavoitteiden suhteen, koetta kurssilla ei ole. Tarkemmat arvosteluperusteet täällä.

Ohjelmistotuotanto

Kun tehdään pientä ohjelmaa omaan käyttöön, ei työskentelymenetelmillä ole suurta merkitystä. Kun ohjelmiston koko on suurempi ja erityisesti, jos sitä tehdään useamman ihmisen toimesta ulkoiselle käyttäjälle tai tilaajalle, ei pelkkä häkkeröinti enää tuota optimaalista tulosta. Tarvitaankin jonkinlainen systemaattinen menetelmä ohjaamaan ohjelmistokehittäjien toimintaa ja varmistamaan, että ohjelmistosta tulee käyttäjien käyttötarkoitukseen sopiva.

Ohjelmiston systemaattinen tekeminen, eli ohjelmistotuotanto (engl. Software engineering) sisältää useita erilaisia aktiviteettejä, joiden aikana tekemisen fokus on hieman erilaisissa asioissa. Näitä aktiviteetteja tai vaiheita niinkuin niitä joskus nimitetään ovat seuraavat

  • vaatimusmäärittely jonka tehtävä on selvittää, kuinka ohjelmiston halutaan toimivan
  • suunnittelu jonka aikana mietitään, miten halutunkaltainen ohjelmisto tulisi rakentaa
  • toteutusvaiheessa määritelty ja suunniteltu ohjelmisto koodataan
  • testauksen tehtävä taas on varmistaa ohjelmiston laatu, että se ei ole liian buginen ja että se toimii kuten vaatimusmäärittely sanoo
  • ylläpitovaiheessa ohjelmisto on jo käytössä ja siihen tehdään bugikorjauksia ja mahdollisia laajennuksia.

Katsotaan vielä kutakin vaihetta hieman tarkemmin.

Käytetään seuraavassa esimerkkinä kurssia varten tehtyä yksinkertaista todo-sovellusta.

Vaatimusmäärittely

Vaatimusmäärittelyn aikana kartoitetaan ohjelman tulevien käyttäjien tai tilaajan kanssa se, mitä toiminnallisuutta ohjelmaan halutaan. Ohjelman toiminnalle siis asetetaan asiakkaan haluamat vaatimukset. Tämän lisäksi kartoitetaan ohjelman toimintaympäristön ja toteutusteknologian järjestelmälle asettamia rajoitteita.

Vaatimusmäärittelyn tuloksena on useimmiten jonkinlainen dokumentti, johon vaatimukset kirjataan. Dokumentin muoto vaihtelee suuresti, se voi olla paksu mapillinen papereita tai vaikkapa joukko postit-lappuja.

Todo-sovelluksen vaatimusmäärittely

Esimerkkisovelluksemme on siis klassinen TodoApp, eli sovellus, jonka avulla käyttäjien on mahdollista pitää kirjaa omista tekemättömistä töistä, eli todoista.

Vaatimusmäärittely kannattaa yleensä aloittaa tunnistamalla järjestelmän erityyppiset käyttäjäroolit. Sovelluksellamme ei ole toistaiseksi muuta kuin normaaleja käyttäjiä. Jatkossa sovellukseen saatetaan lisätä myös ylläpitäjän oikeuksilla varustettu käyttäjärooli.

Kun sovelluksen käyttäjäroolit ovat selvillä, mietitään mitä toiminnallisuuksia kunkin käyttäjäroolin halutaan pystyvän tekemään sovelluksen avulla.

Todo-sovelluksen normaalien käyttäjien toiminnallisuuksia ovat esim. seuraavat

  • käyttäjä voi luoda järjestelmään käyttäjätunnuksen
  • käyttäjä voi kirjautua järjestelmään
  • kirjautumisen jälkeen käyttäjä näkee omat tekemättömät työt eli todot
  • käyttäjä voi luoda uuden todon
  • käyttäjä voi merkitä todon tehdyksi, jolloin todo häviää listalta

Ylläpitäjän toiminnallisuuksia voisivat olla esim. seuraavat

  • ylläpitäjä näkee tilastoja sovelluksen käytöstä
  • ylläpitäjä voi poistaa normaalin käyttäjätunnuksen

Ohjelmiston vaatimuksiin kuuluvat myös toimintaympäristön rajoitteet. Todo-sovellusta koskevat seuraavat rajoitteet

  • ohjelmiston tulee toimia Linux- ja OSX-käyttöjärjestelmillä varustetuissa koneissa
  • käyttäjien ja todojen tiedot talletetaan paikallisen koneen levylle

Vaatimusmäärittelyn aikana hahmotellaan yleensä myös sovelluksen käyttöliittymä.

Kurssin aiemmissa versioissa käyttäjien vaatimukset dokumentointiin käyttötapauksina (engl. use case). Käytämme tällä kurssilla hieman kevyempää tapaa, ja kirjaamme järjestelmältä toivotun toiminnallisuuden vapaamuotoisena ranskalaisista viivoista koostuvana feature-listana. Katso tarkemmin Todo-sovelluksen alustavasta vaatimusmäärittelystä.

Suunnittelu

Ohjelmiston suunnittelu jakautuu yleensä kahteen erilliseen vaiheeseen.

Arkkitehtuurisuunnittelussa määritellään ohjelman rakenne karkealla tasolla

  • mistä suuremmista rakennekomponenteista ohjelma koostuu
  • miten komponentit yhdistetään, eli minkälaisia komponenttien väliset rajapinnat ovat
  • mitä riippuvuuksia ohjelmalla on esim. tietokantoihin ja ulkoisiin rajapintoihin

Arkkitehtuurisuunnittelua tarkentaa oliosuunnittelu, missä mietitään ohjelmiston yksittäisten komponenttien rakennetta, eli minkälaisista luokista komponentit koostuvat ja miten luokat kutsuvat toistensa metodeja sekä mitä apukirjastoja luokat käyttävät.

Myös ohjelmiston suunnittelu, erityisesti sen arkkitehtuuri dokumentoidaan usein jollain tavalla. Joskus tosin dokumentaatio on hyvin kevyt, esim. valkotaululle piirretty kaavio tai se voi jopa puuttua kokonaan ja ajatellaankin että hyvin muotoiltu koodi voi korvata dokumentoinnin.

Testaus

Toteutuksen yhteydessä ja sen jälkeen järjestelmää testataan. Testauksessa on monta erilaista näkökulmaa, eli pääasiallista kiinnostuksen kohdetta. Näitä eri näkökulmia nimitetään usein testaustasoiksi. Testauksen terminologia vaihtelee hieman mutta yleisimmin puhutaan kolmesta testaustasosta eli yksikkötestauksesta, integraatiotestauksesta ja järjestelmätestauksesta.

Yksikkötestauksessa (engl. unit testing) tutkitaan yksittäisten metodien ja luokkien toimintaa. Yksikkötestauksen tekee usein testattavan luokan ohjelmoija ja hyvä tapa on tehdä luokalle yksikkötestit samalla kun luokka ohjelmoidaan.

Kun erikseen ohjelmoidut komponentit (eli luokat tai luokkien muodostamat kokoelmat) yhdistetään, suoritetaan integraatiotestaus (engl. integration testing), jossa varmistetaan erillisten komponenttien yhteentoimivuus. Myös integraatiotestit tehdään useimmiten ohjelmoijien toimesta.

Järjestelmätestauksessa (engl. system testing) testataan järjestelmää kokonaisuutena ja verrataan, että se toimii vaatimusdokumentissa sovitun määritelmän mukaisesti. Järjestelmätestauksessa testien näkökulma on sama kuin loppukäyttäjän, eli testit suoritetaan ohjelmiston käyttöliittymän kautta. Järjestelmätestauksen suorittavat usein testauksen ammattilaiset.

Vesiputousmalli

Ohjelmistoja on perinteisesti tehty vaihe vaiheelta etenevän vesiputousmallin (engl. waterfall model) mukaan. Vesiputousmallissa edellä esitellyt ohjelmistotuotannon vaiheet suoritetaan peräkkäin:

Vesiputousmallissa suoritetaan siis ensin vaatimusmäärittely, jonka seurauksena kirjoitetaan vaatimusdokumentti, johon pyritään kokoamaan kaikki ohjelmalle osoitettavat vaatimukset mahdollisimman tarkasti dokumentoituna. Määrittelyvaiheen päätteeksi vaatimusdokumentti jäädytetään. Jäädytettyä vaatimusmäärittelyä käytetään usein ohjelman kehittämisen vaatimien resurssien arvioinnin perustana ja myös sopimus ohjelman hinnasta saatetaan tehdä vaatimusmäärittelyn pohjalta.

Vaatimusmäärittelyä seuraa suunnitteluvaihe, joka myös dokumentoidaan tarkoin. Pääsääntöisesti suunnitteluvaiheen aikana ei enää tehdä muutoksia määrittelyyn. Joskus tämäkin on tarpeen. Suunnittelu pyritään tekemään niin täydellisenä, että ohjelmointivaiheessa ei enää ole tarvetta muuttaa suunnitelmia.

Suunnittelun jälkeen toteutetaan ohjelman yksittäiset komponentit ja tehdään niille yksikkötestaus. Tämän jälkeen erilliset komponentit liitetään yhteen eli integroidaan ja suoritetaan integrointitestaus.

Integroinnin jälkeen ohjelmalle tehdään järjestelmätestaus, eli testataan, että ohjelmisto toimii kokonaisuutena niin kuin määrittelydokumentissa on määritelty.

Vesiputousmalli on monella tapaa ongelmallinen. Mallin toimivuus perustuu siihen oletukseen, että ohjelman vaatimukset pystytään määrittelemään täydellisesti ennen kuin suunnittelu ja ohjelmointi alkaa. Näin ei useinkaan ole. On lähes mahdotonta, että asiakkaat pystyisivät tyhjentävästi ilmaisemaan kaikki ohjelmalle asettamansa vaatimukset. Vähintäänkin riski sille, että ohjelma on käytettävyydeltään huono, on erittäin suuri. Usein käy myös niin, että vaikka ohjelman vaatimukset olisivat kunnossa vaatimusten laatimishetkellä, muuttuu toimintaympäristö (tapahtuu esim. yritysfuusio) ohjelman kehitysaikana niin ratkaisevasti, että valmistuessaan ohjelma on vanhentunut. Hyvin yleistä on myös se, että vasta käyttäessään valmista ohjelmaa asiakkaat alkavat ymmärtää, mitä he olisivat ohjelmalta halunneet.

Asiakkaan muuttuvien vaatimuksien lisäksi toinen suuri ongelma on se, että vesiputousmallissa ohjelmistoa aletaan testata verrattain myöhäisessä vaiheessa. Erityisesti integraatiotestauksessa on tyypillistä että ohjelmasta löydetään pahoja ongelmia, joiden korjaaminen hidastaa ohjelmiston valmistumista paljon ja käy kalliiksi.

Ketterä ohjelmistokehitys

Vesiputousmallin heikkoudet ovat johtaneet viime vuosina yleistyneiden ketterien (engl. agile) ohjelmistokehitysmenetelmien käyttöönottoon.

Ketterissä menetelmissä lähdetään oletuksesta, että vaatimuksia ei voi tyhjentävästi määritellä ohjelmistokehitysprosessin alussa. Koska näin ei voida tehdä, ei sitä edes yritetä vaan pyritään toimimaan niin, että asiakkaan vaatimukset saadaan tarkennettua pikkuhiljaa ohjelmiston kehitysprosessin aikana ja lopputuloksesta saadaan sitä kautta mahdollisimman halutun kaltainen.

Ketterä ohjelmistokehitys etenee yleensä siten, että ensin kartoitetaan pääpiirteissään ohjelman vaatimuksia ja ehkä hahmotellaan järjestelmän alustava arkkitehtuuri. Tämän jälkeen suoritetaan useita iteraatioita (joista käytetään yleisesti myös nimitystä sprintti), joiden aikana ohjelmaa rakennetaan pala palalta eteenpäin. Kussakin iteraatiossa suunnitellaan ja toteutetaan valmiiksi pieni osa ohjelman vaatimuksista. Vaatimukset voivat myös tarkentua koko prosessin ajan.

Yksittäinen iteraatio, joka on kestoltaan tyypillisesti 1-4 viikkoa, siis lisää järjestelmään pienen osan koko järjestelmän toivotusta toiminnallisuudesta. Tyypillisesti tärkeimmät ja toteutuksen kannalta haasteellisimmat ja riskialttiimmat toiminnallisuudet toteutetaan ensimmäisillä iteraatioilla. Yksi iteraatio sisältää toteutettavaksi valittujen vaatimusten tarkennuksen, suunnittelun, toteutuksen sekä testauksen.

Jokainen iteraatio tuottaa toimivan ja toteutettujen ominaisuuksien kannalta testatun järjestelmän. Asiakas pääsee kokeilemaan järjestelmää jokaisen iteraation jälkeen. Tällöin voidaan jo aikaisessa vaiheessa todeta, onko kehitystyö etenemässä oikeaan suuntaan ja vaatimuksia voidaan tarvittaessa tarkentaa ja lisätä.

Jokainen iteraatio siis sisältää määrittelyä, suunnittelua, ohjelmointia ja testausta ja jokaisen iteraation jälkeen saadaan asiakkaalta palautetta siitä, onko kehitystyö etenemässä oikeaan suuntaan:

Ketterässä ohjelmistokehityksessä dokumentointi ei ole yleensä niin keskeisessä osassa kuin perinteisissä menetelmissä.

Vähäisemmän dokumentaation sijaan testauksella ja ns. jatkuvalla integroinnilla on hyvin suuri merkitys. Yleensä pyritään siihen, että järjestelmään lisättävät uudet komponentit testataan välittömästi ja pyritään heti integroimaan kokonaisuuteen; tästä työskentelytavasta käytetään nimitystä jatkuva integrointi (engl. continuous integration). Näin uusia versioita järjestelmästä syntyy jopa päivittäin.

Uusien komponenttien toimiminen pyritään varmistamaan perinpohjaisella automaattisella testauksella. Joskus jopa “testataan ensin”, eli jo ennen uuden komponentin toteuttamista ohjelmoidaan komponentin toimintaa testaavat testitapaukset. Testitapausten valmistuttua toteutetaan komponentti ja siinä vaiheessa kun komponentti läpäisee testitapaukset, se integroidaan muuhun kokonaisuuteen.

Erilaisia ketteriä ohjelmistokehitysmenetelmiä on olemassa lukuisia, näistä tunnetuin nykyään on Scrum.

Ketterät menetelmät ovat nykyään vallitseva tapa tehdä ohjelmistoja. Ketterien menetelmien rinnalle ovat viime vuosina nousseet ketteryyden ideaa hieman jalostavat Lean-menetelmät. Palaamme aiheeseen tarkemmin kurssilla Ohjelmistotuotanto.

Tämän kurssin harjoitustyö pyritään tekemään osittain ketterien menetelmien hengessä, eli vaatimusmäärittely ja suunnittelu pidetään kevyenä ja ohjelmaa aletaan toteuttaa jo heti alkuvaiheessa. Ohjelmasta pyritään mahdollisuuksien mukaan tekemään jokaisen iteraation eli viikon päätteeksi toimiva versio jota sitten viikko viikolta laajennetaan. Kurssin vaatimaa dokumentaatiota tehdään osin matkan varrella.

Ensimmäisen viikon harjoitukset

Lue tehtävänannot kohdista “Komentorivin harjoittelua” ja “Versionhallinta”. Jos niissä käsitellyt asiat ovat tuttuja (kuten kurssin esitietovaatimuksien mukaan pitäisi olla), sinun ei tarvitse tehdä näitä harjoituksia. Jos kuitenkin yhtään epäilet osaamistasi, tee harjoitukset tehtävänantojen mukaan! Et saa siitä ylimääräisiä pisteitä, mutta tulet jatkossa tarvitsemaan vastaavia taitoja tällä kurssilla.

Mikäli komentorivi- ja versionhallintaharjoitusten asiat ovat tuttuja, tee joka tapauksessa seuraavat asiat:

  1. Luo paikallinen repositorio harjoitustyölle ja viikkoharjoituksille. Voit antaa sille nimeksi ot-harjoitustyo.
  2. Luo repositoriosi hakemistoon tiedosto README.md. Kirjoita sinne otsikko “Ohjelmistotekniikka, harjoitustyö” ja kerro yhdellä virkkeellä, mitä olet tekemässä (tämä saa vielä muuttua: harjoitustyön oikea alustava vaatimusmäärittely tulee vasta seuraavalla viikolla). Muotoile tekstisi markdown-notaatiota käyttäen siten, että mukaan tulee otsikon lisäksi tavallista tekstiä, joka sisältää lihavoituja ja kursivoituja osuuksia.
  3. Luo myös alihakemisto nimeltä laskarit ja lisää sinne tiedosto nimeltä viikko1.md. Kirjoita tiedostoon, että komentorivi ja versionhallinta ovat jo tuttuja.
  4. Lisää ja kommitoi README.md ja alihakemisto laskarit repositorioosi.
  5. Luo GitHub-repositorio ja liitä se paikallisen repositoriosi etärepositorioksi.
  6. Pushaa paikallisen repositoriosi sisältö GitHubiin.
  7. Editoi GitHubissa tiedostoa README.md: lisää siihen linkki alihakemistoon laskarit.
  8. Rekisteröi omat tietosi ja luomasi GitHub-repositorio Labtooliin.

(Ensimmäisen viikon harjoituspisteeseen siis riittää edellä lueteltujen asioiden tekeminen. Jos et osaa tehdä niitä, toimi alla olevien komentorivi- ja versionhallintaharjoitusten ohjeiden mukaisesti ja saat harjoituspisteen sitä kautta.)

Koska säästit aikaa komentorivi- ja versionhallintaharjoitusten sivuuttamisella, tutustu jo alustavasti seuraavan viikon kurssimateriaaliin. Sivun loppupuolelta löydät ohjeita harjoitustyön aiheenvalintaan ja alustavan määrittelydokumentin kirjoittamiseen. Mieti, miten aiot harjoitustyössäsi edetä ja näetkö siinä joitain ongelmallisia kohtia. Mikäli niin haluat, mikään ei estä sinua jo käytännössä tekemästä 2. viikon harjoituksia ja/tai harjoitustyösi määrittelydokumenttia. Ne kuitenkin arvioidaan vasta kurssin toisen viikon jälkeen.

Komentorivin harjoittelua (tee nämä harjoitukset jos ei tunnu tutulta)

Graafisten käyttöliittymien olemassaolosta huolimatta ohjelmistoalalla on edelleen erittäin tärkeää hallita komentorivin eli terminaalin käyttö. Opettele käyttämään “riittävästi” komentoriviä (ks. alla oleva lista). Opettelu käy ehkä helpoiten tekemällä Tietokone työvälineenä-kurssin ensimmäisen osan Komentorivi tehtävät 1-13.

Tämän tehtävän jälkeen sinun tulisi hallita seuraavat käsitteet:

  • Root directory
  • Home directory
  • Parent directory
  • Child directory
  • Working directory
  • .. ja *

Lisäksi sinun tulee osata käyttää seuraavia komentoja:

  • pwd
  • cd
  • ls, ls -a, ls -l, ls -t
  • mkdir
  • touch
  • cp
  • rm, rm -r
  • mv

Tulet tarvitsemaan komentorivin käyttötaitoja tällä kurssilla ja muutenkin opinnoissasi.

Tehtävä 1: Komentorivin harjoittelua

Saman Tietokone työvälineenä-kurssin materiaalin toisesta osasta voi olla paljonkin hyötyä tässä ja seuraavissa tehtävissä.

Ota ssh-yhteys linuxpalvelimeen melkki.cs.helsinki.fi, melkinpaasi.cs.helsinki.fi tai melkinkari.cs.helsinki.fi. Linuxilla, macilla ja Windows 10:llä yhteys otetaan komentoriviltä komennolla ssh kayttajatunnus@palvelimenosoite. Vanhemmilla Windows versioilla ssh-yhteyden ottaminen onnistuu esimerkiksi putty:llä.

Kirjauduttuasi laitoksen palvelimelle, tee seuraavat toimenpiteet:

  • Luo kotihakemistoosi hakemisto kurssit
    • HUOM: joidenkin kohdalla melkillä on ollut ongelmia kotihakemiston asetuksissa ja esim. hakemiston luomisen seurauksena on virhe ‘permission denied’. Jos törmäät ongelmaan, lähetä viesti osoitteeseen it-support@cs.helsinki.fi ja raportoi ongelmaksi “ei oikeuksia kotihakemistoon melkillä”
    • Kokeile myös jos kirjaantuminen toiselle koneelle, esim. melkinpaasi.cs.helsinki.fi tuottaisi paremman tuloksen
  • Luo hakemistolle kurssit alihakemisto ot2023
  • Ja luomallesi hakemistolle alihakemisto viikko1
  • Mene kotihakemistoosi ja luo sen alle hakemisto temp
  • Mene hakemistoon temp
  • Hae osoitteessa https://raw.githubusercontent.com/ohjelmistotekniikka-hy/ohjelmistotekniikka-hy.github.io/master/materiaali/python/unicafe.zip oleva tiedosto wget-ohjelmalla
    • Wget toimii siten, että sille annetaan ladattava tiedosto parametriksi
  • Haettu tiedosto on zip-paketti, pura se unzip-ohjelmalla
    • Myös unzip toimii siten, että sille annetaan purettava tiedosto parametriksi
  • Komennon suorittamisen jälkeen hakemistoon on ilmestynyt hakemisto unicafe
  • Siirrä hakemisto hakemiston kurssit/ot2023/viikko1 alihakemistoksi
  • Poista zip-paketti
  • Poista hakemisto temp

Mene tämän jälkeen kotihakemistoon ja anna komento tree kurssit. Copypastea komennon tulostus talteen, tarvitset sitä myöhemmin.

Tab complete

Komentoriviä käyttäessä kannattaa ehdottomasti totutella tab-completen käyttöön. Tab on näppäin, joka näyttää suunnilleen seuraavalta

Tab:ia painamalla voit komentorivillä täydentää kirjoittamasi komennon nimen tai parametrin. Esim. jos olet siirtymässä hakemistoon nimeltään ohjelmistotekniikka-syksy-2020, riittää, että kirjoitat cd oh ja painat tabia. Jos hakemistossasi ei ole muita tiedostoja tai hakemistoja, jotka alkavat merkeillä oh, nimi täydentyy. Jos on, niin voit joutua kirjoittamaan merkin tai kaksi lisää. Jos tiedostoja on useampia etkä ole varma oikeasta nimestä, painamalla tabia useamman kerran näet mahdolliset vaihtoehdot.

Myös komentojen nimet voi täydentää tab-completella. Esim. haluat avata chromium-browser web-selaimen komentoriviltä, riittää että kirjoitat chro ja painat tabia. Komennon nimi täydentyy.

Ei pidä myöskään unohtaa nuolta ylöspäin. Sen avulla voit selata aiemmin kirjoittamiasi komentoja.

Yhtäaikaiset terminaalit ja terminaalin tabit

Aloitteleva komentorivin käyttäjä pitää usein ainoastaan yhtä terminaali-ikkunaa kerrallaan auki. Useimmissa tilanteissa työtehosi moninkertaistuu, jos avaat useita terminaaleja näytöllä tai avaat yhteen terminaaliin useita “tabeja” eli välilehtiä. Uuden tabin saat avautumaan painamalla yhtä aikaa ctrl, shift ja t tai sovelluksen valikosta (joka laitoksen Linuxeissa sijaitsee ruudun yläreunassa).

Versionhallinta (tee nämä harjoitukset jos ei tunnu tutulta)

Tutustumme seuraavaksi versionhallintaan.

Mitä tarkoitetaan versionhallinnalla? Lainaus sivulta https://www.atlassian.com/git/tutorials

Version control systems are a category of software tools that help a software team manage changes to source code over time. Version control software keeps track of every modification to the code in a special kind of database. If a mistake is made, developers can turn back the clock and compare earlier versions of the code to help fix the mistake while minimizing disruption to all team members.

Vaikka ylläoleva puhuu versionhallinnasta ohjelmistotiimien yhteydessä, kannattaa versionhallintaa käyttää oikeastaan yhdenkin hengen projekteissa ja muunkinlaisen materiaalin, kuin koodin hallinnoimiseen. Esim. tämän kurssin kaikki materiaali on talletettu versionhallintaan.

Nykyään suosituin versionhallintaohjelmisto on git. Tutustumme tänään gitin alkeisiin.

HUOM: Git-tehtävät tulee tehdä tietokoneella, jolle on asennettu Git. Monilla macOS- ja Linux-käyttöjärjestelmien tietokoneilla Git on valmiiksi asennettuna. Asian voi tarkistaa suorittamalla oman tietokoneen terminaalissa komennon:

git --version

Jos komento ei tulosta Git-version numeroa, tutustu Git-asennusohjeisiin. Windows-tietokoneilla asennuksessa ja komentojen suorituksessa voi käyttää esimerkiksi Windows Subsystem for Linux -työkalua.

Jos komennon tulostama gitin versio taas on pienempi kuin 2.23.0, seuraavissa tehtävissä käytetty git restore -komento ei toimi. Voit kuitenkin käyttää git reset HEAD- ja git checkout -komentoja, joista saat lisätietoa Tietokone työvälineen -kurssin materiaaleista.

Tehtävä 2: Git-konfiguraatioita

Avaa terminaali omalla koneellasi. Seuraavat tehtävät tehdään siis paikallisesti, ei melkillä!

Määrittele gitille oma nimesi sekä käyttämäsi email-osoite antamalla komennot:

 git config --global user.name "Your Name"
 git config --global user.email you@example.com

Varmista komennolla git config -l, että määrittelyt menivät oikein.

Määritellään vielä git käyttämään sopivia värejä komennolla git config --global color.ui ja vaihdetaan gitin käyttämäksi oletuseditoriksi nano komennolla git config --global core.editor nano

Jos käytät vimiä, voit jättää oletuseditorin muuttamatta.

Tee vielä seuraava konfiguraatio:

git config --global push.default matching

Tämä liittyy git push-komennon oletusarvoiseen toiminnallisuuteen. Komennosta lisää myöhemmin.

Tehtävä 3: Repositorio

Tee nyt sopiva hakemisto gitin harjoittelua varten ja mene hakemistoon, eli anna esim. komennot:

  • mkdir ot_viikko1
  • cd ot_viikko1

HUOM: varmista nyt että olet luomassasi hakemistossa, eli jos suoritat komennon ls, ei hakemistossa pitäisi olla mitään.

Luodaan hakemistosta paikallinen git-repositorio antamalla komento git init

Git ilmoittaa alustaneensa repositorion:

mluukkai@melkinpaasi:~/ot_viikko1$ git init
Initialised empty Git repository in /home/ad/fshome4/u4/m/mluukkai/Linux/ot_viikko1/.git/

Jos katsot hakemiston sisältöä komennolla ls -la huomaat, että hakemiston sisälle on ilmestynyt hakemisto .git. Git käyttää luotua hakemistoa pitääkseen kirjaa repositorioon talletetuista tiedostoista.

HUOM: koska hakemiston nimi (.git) alkaa pisteellä, ei komento ls näytä sitä oletusarvoisesti. Parametri a näyttää myös pisteellä alkavat tiedostot ja hakemistot. Kokeile, miten ls -a ja ls -la eroavat toisistaan!

Pysy edelleen repositorion sisältävässä hakemistossasi ot_viikko1.

Luo hakemistoon tiedosto nimeltään tiedosto.txt, esim. komennolla touch. Luotuasi tiedoston, suorita komento git status:

mluukkai@melkinpaasi:~/ot_viikko1$ touch tiedosto.txt
mluukkai@melkinpaasi:~/ot_viikko1$ git status
On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	tiedosto.txt

nothing added to commit but untracked files present (use "git add" to track)
mluukkai@melkinpaasi:~/ot_viikko1$

Git ilmoittaa, että on olemassa tiedosto, joka on tilassa untracked, eli tiedostoa ei ole lisätty versionhallinnan pariin.

Kuten komennon tuloste kertoo, tiedoston lisääminen gitin alaisuuteen (…to include in what will be committed) tapahtuu komennolla git add tiedosto.txt

Suorita lisäys ja sen jälkeen komento git status:

mluukkai@melkinpaasi:~/ot_viikko1$ git add tiedosto.txt
mluukkai@melkinpaasi:~/ot_viikko1$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

	new file:   tiedosto.txt

Git kertoo nyt, että tiedosto.txt on niiden muutosten joukossa, jotka voidaan commitoida.

Tehtävä 4: Commitit

Commitoimisella tarkoitetaan tiedostojen ja hakemistojen sekä niihin liittyvien muutosten tallentamista git-repositorioon.

Suoritetaan commitointi antamalla komento git commit -m "tiedosto.txt luotu"

mluukkai@melkinpaasi:~/ot_viikko1$ git commit -m "tiedosto.txt luotu"
[master (root-commit) 0e12cfa] tiedosto.txt luotu
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 tiedosto.txt

Suorita jälleen komento git status

mluukkai@melkinpaasi:~/ot_viikko1$ git status
On branch master
nothing to commit, working tree clean

Git ilmoittaa, että working tree clean, eli hakemistosi on samassa tilassa kuin git-repositorio.

Tehtävä 5: Working directory, index ja staging

Muista käyttää tab-completea tehtäviä tehdessäsi!

Kun teet muutoksia hakemistosi alla oleviin tiedostoihin (tai hakemistoihin), kohdistuvat muutokset working directoryyn eli työhakemistoon.

  • Tee jokin muutos tiedostoon tiedosto.txt
    • Käytä tiedostojen editointiin nano-editoria. Editori käynnistyy komentoriviltä komennolla nano tiedosto.txt
    • Saat tallennettua nanossa tiedoston painamalla yhtä aikaa ctrl ja o
    • Editori sulkeutuu painamalla ctrl ja x
  • Luo hakemistoon uusi tiedosto, nimeltään toinen.txt

Suorita jälleen git status

mluukkai@melkinpaasi:~/ot_viikko1$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   tiedosto.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	toinen.txt

no changes added to commit (use "git add" and/or "git commit -a")

Git ilmoittaa nyt, että uusi tiedosto on untracked ja että aiemmassa tiedostossa on muutoksia, jotka eivät ole staged for commit.

Toimitaan ohjeen mukaan eli lisätään muutokset ja uusi tiedosto commitoitavien joukkoon. Molempien tiedostojen yhtäaikainen “addaaminen” onnistuu komennolla git add .

Tarkistetaan taas tilanne komennolla git status

mluukkai@melkinpaasi:~/ot_viikko1$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   tiedosto.txt
	new file:   toinen.txt

Sekä muutos että uusi tiedosto ovat nyt valmiina committoitavaksi.

Committointi onnistuu komennolla git commit. Kuten edelliselläkin kerralla, annetaan komennolle parametrina commit-viesti, eli merkkijono, joka kuvaa mitä muutoksia uusi commit tuo edelliseen nähden:

git commit -m "muutos ja lisäys"

Tarkasta committoinnin jälkeen jälleen tilanne komennolla git status.

HUOM jos suoritat commitoinnin vahingossa ilman commit-viestiä, eli parametria -m, avaa git tekstieditorin ja olettaa että haluat kirjoittaa commit-viestin editoriin. Jos et määritellyt alun ohjeen mukaan gitille editoriksi nanoa, avautuu oletusarvoinen editori vim ja joudut kenties googlaamaan, miten pääset pois editorista.

Tiedostot ja niihin tehdyt muutokset voivat siis olla gitin suhteen kolmessa eri tilassa.

  • Aluksi tiedostot (tai niihin tehdyt muutokset) ovat vain working directoryssä ja git ei noteeraa niitä ennen kuin ne lisätään komennolla git add
  • Tämän jälkeen tiedostot ovat valmiina commitoitavaksi. Gitin terminologian mukaan valmiina committoitavaksi olevat tiedostot ovat staging-alueella
  • Komento git commit siirtää stagingissa olevat muutokset repositorioon eli luo uuden commitin

Seuraava kuva havainnollistaa sitä, miten tiedoston tila vaihtuu git-komentoja tekemällä.

Kun tiedosto luodaan, menee se gitin working directoryyn. Komennolla git add tiedosto siirtyy staging-alueelle, eli valmiiksi committointia varten. Stagingissa oleva tiedosto viedään (eli “commitoidaan”) repositorioon komennolla git commit. Kun committoitua tiedostoa taas editoidaan, menevät muutokset jälleen working directoryyn.

Git log

Jokainen komennon git commit suorittaminen siis synnyttää repositorioon uuden commitin, eli uuden “tilan”. Komennolla git log on mahdollista nähdä, mitä committeja repositorio sisältää:

mluukkai@melkinpaasi:~/ot_viikko1$ git log
commit 6aff75ab51d14d7cb9a72867ba13d9782d06c7ff (HEAD -> master)
Author: Matti Luukkainen <mluukkai@iki.fi>
Date:   Sun Oct 7 19:33:32 2018 +0300

    muutos ja lisäys

commit 9e6a83d058c9564e8a390f8766845d45b365f360
Author: Matti Luukkainen <mluukkai@iki.fi>
Date:   Sun Oct 7 19:32:12 2018 +0300

    tiedosto.txt luotu
mluukkai@melkinpaasi:~/ot_viikko1$

Gitin logi kertoo jokaisen commitin ajan, tekijän, viestin ja tunnisteen. Tunnisteita käytetään, jos on esim. tarvetta palata johonkin vanhan commitin tilaan.

Voit selata logia nuolinäppäimillä. Pääset ulos git log:ista painamalla q.

Tehtävä 6: Harjoittelua

Muista käyttää komentoa git status mahdollisimman usein. Älä myöskään unohda tab-completea!

  • Luo tiedosto kolmas.txt
  • Lisää se commitoitavaksi ja commitoi
  • Muuta tiedostojen toinen.txt ja kolmas.txt sisältöä ja commitoi muutokset
  • Luo hakemisto stuff ja sen sisälle jokin tiedosto
  • Lisää muutokset committoitavaksi ja committoi
    • Huomaa, että hakemiston lisääminen riittää, sen sisältämät tiedostot tulevat automaattisesti lisätyksi
  • Katso miltä git-logi näyttää

Tehtävä 7: gitk

Gitin committeja voi tarkastella myös graafisella gitk-komennolla.

  • gitk-komento toimii Windowsilla ainakin GitHub for Windowsin Git Shellissä.
  • Saat asennettua Maciin gitk:n tämän ohjeen avulla
  • Jos gitk ei jostain syystä toimi, voit asentaa Sourcetree-työkalun

Suorita komento repositoriossa:

Vasemmalla yläkulmassa näet kaikki commitit. Uusin tilanne ylimpänä. Uusimman commitin nimi on master. Klikkaamalla commitia, näet muissa ikkunoissa commitiin liittyviä tietoja. Oikealla alakulmassa näet ne tiedostot, jotka ovat muuttuneet commitissa (jos valinta on patch) tai ne tiedostot, joita repositoriossa oli olemassa commitin aikana (jos valinta on tree). Vasemmassa alakulmassa pystyt tarkastelemaan commitin tiedostoihin tekemiä muutoksia tai tiedostojen tilaa commitin aikana. Valinnat ovat hieman hämäävät, sillä ne toimivat eri tavoin riippuen oikean puolen moodista.

Vastaava näkymä OSX:n Sourcetree-ohjelmalla tarkasteltaessa:

Seuraavaa tehtävää tehdessäsi kannattaa terminaaliin avata uusi välilehti, jotta voit pitää gitk:ta käynnissä.

  • Kopioi tiedostoon tiedosto.txt jostain paljon tekstiä ja commitoi tiedosto
  • Poista nyt osa tiedoston tekstistä ja lisää tiedostoon hieman lisää tekstiä
  • commitoi muutosten jälkeen
  • Päivitä gitk:n näkymä (file/update) ja katso miten muutokset näkyvät (tarkastele kahta ylintä committia)
    • Valitse oikeasta alakulmasta patch ja vasemmasta diff
    • Näin näet commitin aiheuttamat muutokset diff-muodossa
    • Jos oikealta on valittuna tree, näkyy vasemmalla puolella (valinnasta riippumatta) tiedostojen commitin aikainen tilanne
  • Jos käytät sourcetreetä, sen pitäisi päivittyä automaattisesti ja näyttää muutos diff-muodossa

Tehtävä 8: Tiedoston poistaminen ja uudelleennimentä

  • Poista tiedosto toinen.txt
  • Suorita git status
  • Commitoi muutos
    • Poista ensin tiedosto gitin alaisuudesta komennolla git rm
  • varmista komennolla git status, että kaikki on niinkuin kuuluukin
  • muuta tiedoston tiedosto.txt nimeksi eka.txt
    • uudelleennimentä tapahtuu komennolla mv
  • Suorita git status
    • Miten git käsittelee uudelleennimennän?
  • Commitoi muutos

Tehtävä 9: git add -p

  • Tee jotain muutoksia tiedostoihin eka.txt ja kolmas.txt
    • Tee sekä lisäyksiä että poistoja
  • lisää ne commitoitavaksi komennolla git add -p
    • Git näyttää nyt jokaisen tekemäsi muutoksen patch-muodossa ja pyytää varmistamaan lisätäänkö muutos commitoivaksi
    • Hyväksy painamalla y ja enter
  • Commitoi muutokset
  • Tee tiedostoihin tehtyjen muutosten commitoitavaksi lisääminen aina komennolla git add -p, näin pääset tarkastamaan, että muutokset ovat juuri ne mitä oletat olevasi lisäämässä
  • Huomaa, että kokonaan uudet tiedostot eivät siirry committoitavaksi komennolla git add -p

Tehtävä 10: Muutosten peruminen

Joskus tiedostoihin tulee tehtyä muutoksia, jotka on tarpeen perua

  • Tee nyt joku muutos tiedostoon eka.txt, älä lisää tiedostoa committoitavaksi
  • Suorita komento git status
mluukkai@melkinpaasi:~/ot_viikko1$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   eka.txt

no changes added to commit (use "git add" and/or "git commit -a")

Kuten oletettua, git kertoo että olemme tehneet muutoksia, jotka eivät ole “staged for commit”, eli lisättyjä commitoitavaksi.

  • Päätetäänkin perua muutokset. Se onnistuu komennolla git restore eka.txt
  • Kun suoritat uudelleen komennon git status huomaat, että working directory ei enää sisällä muutoksia:
mluukkai@melkinpaasi:~/ot_viikko1$ git restore eka.txt
mluukkai@melkinpaasi:~/ot_viikko1$ git status
On branch master
nothing to commit, working trean clean
  • Varmista vielä, että tiedoston sisältö on sama kuin ennen muutoksia

Myös stagingiin viety eli valmiina committoitavaksi oleva muutos voidaan perua.

  • Tee muutoksia tiedostoon kolmas.txt ja lisää se committoitavaksi. Älä kuitenkaan committoi.
  • Git statuksen pitäisi näyttää seuraavalta
mluukkai@melkinpaasi:~/ot_viikko1$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)

	modified:   kolmas.txt

mluukkai@melkinpaasi:~/ot_viikko1$

Ohje muutoksen perumiseen löytyy git statuksen tulosteesta.

  • Suorita muutokset peruva komento git restore --staged kolmas.txt
  • Katsotaan jälleen git status
mluukkai@melkinpaasi:~/ot_viikko1$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)

	modified:   kolmas.txt

no changes added to commit (use "git add" and/or "git commit -a")

Tiedosto ei siis enää ole staged-tilassa, muutokset ovat kuitenkin working directoryssä, eli jos katsot tiedoston sisällön, muutokset ovat vielä olemassa

  • Pääset perumaan muutokset kokonaan antamalla komennon git restore kolmas.txt
  • Varmista, että tiedosto on palannut muutoksia edeltävään tilaan

Seuraavassa tiedoston tilaa kuvaava kaavio täydennettynä, eli jos tiedosto on lisätty committoitavaksi, eli se on staged, voidaan muutos perua komennolla git restore --staged. Tällöin muutokset kuitenkin vielä jäävät tiedostoon, eli ovat working directoryssä. Tiedosto saadaan palautettua repositoriossa olevaan edellisen commitin tilaan komennolla git restore.

Tehtävä 11: Harjoittelua

  • luo repositoriosi sisälle hakemisto tiedostoja ja hakemiston sisälle tiedostot file1, file2 ja file3
  • commitoi muutokset
    • muista miten pystyt lisäämään kokonaisen hakemiston sisällön commitoitavaksi yhdellä komennolla
  • muuta tiedoston file1 sisältöä ja poista tiedosto file2
  • peru muutokset!
  • muuta tiedoston file3 sisältöä, lisää commitoitavaksi
  • peru muutokset!
  • poista tiedosto file1 ja uudelleennimeä tiedosto file2 tiedostoksi file22
  • committoi

Suorita repositoriossa komento git log --stat | cat ja ota komennon tulos talteen, tulet tarvitsemaan sitä myöhemmin!

Tehtävä 12: GitHub

Gitin käytöstä on toki hyötyä jo harjoittelemallammekin tavalla, eli muodostamalla paikallisen koneen hakemistosta repositorio. Pääsemme kuitenkin nauttimaan kertaluokkaa suuremmista hyödyistä liittämällä repositoriomme internetissä olevaan etärepositorioon. Etärepositorion kautta repositorion tiedostot on helppo jakaa useiden koneiden tai/ja useiden käyttäjien kesken.

Internetin johtava paikka etärepositorioiden tallettamiseen on GitHub

Ennen GitHubin käytöönottoa, tee uusi git-repositorio paikalliselle koneelle, seuraavassa oletetaan että hakemiston nimi on ot-harjoitustyo.

HUOM: älä luo uutta repositoriota aiemmin tekemäsi harjoitusrepositorion sisälle!

Esim. seuraavat komennot siirtyvät kotihakemistoon, luovat sen alle hakemiston ot-harjoitustyo, siirtyvät hakemistoon, alustavat sen git-repositorioksi sekä lisäävät ja commitoivat yhden tiedoston repositorioon:

cd
mkdir ot-harjoitustyo
cd ot-harjoitustyo
git init
touch README.md
git add .
git commit -m "initial commit"

Siirrytään sitten GitHubin käyttöön

  • Luo itsellesi tunnus GitHubiin (ellei sinulla jo ole tunnusta)
  • Luo uusi repositorio
    • uuden repositorion luomistoiminto löytyy oikean ylänurkan plus-symboolin alta
  • Älä laita rastia kohtaan Initialize this repository with a README

  • Luo repositorio painamalla vihreää Create repository -nappia

Seuraavaksi haluamme liittää GitHubiin luodun repositorion juuri luodun paikallisen koneen repositorion ot-harjoitustyo etärepositorioksi.

  • Etärepositorion lisääminen onnistuu GitHubiin avautuvan näkymän ohjeiden mukaan
  • Varmista, että kohdasta “Quick setup…” on valittu SSH

  • Kopioi ylempi rivi kohdasta …or push an existing repository from the command line
  • Omassa esimerkissäni rivi on
git remote add origin git@github.com:mluukkai/ot-harjoitustyo.git
  • Pastea rivi komentoriville ja suorita komento painamalla enter
  • Suorita komento git remote -v
  • Tulostus kertoo, että githubin etärepositorio on liitetty paikalliseen repositorioosi nimellä origin
mluukkai@melkki:~/ot-harjoitustyo$ git remote  -v
origin	git@github.com:mluukkai/ot-harjoitustyo.git (fetch)
origin	git@github.com:mluukkai/ot-harjoitustyo.git (push)
  • Origin on etärepositorion oletusarvoinen nimi. Nimi voi olla mikä tahansa ja etärepositorioitakin voi olla useita
  • Voimme siirtää paikallisen repositoriomme tilan etärepositorioon komennolla git push
    • Saatat joutua tekemään ensimmäisen pushin pidemmässä muodossa --set-upstream origin master. Käytettävän haaran nimi voi git-konfiguraatiosta riippuen olla myös main. Käytä siis muotoa -set-upstream origin main, jos edellä mainittu muoto ei toimi
  • Kokeillaan
mluukkai@melkki:~/ot-harjoitustyo$ git push --set-upstream origin master
Warning: Permanently added the RSA host key for IP address '192.30.253.112' to the list of known hosts.
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Tehtävä 13: Julkinen avain

Jos olet jo asettanut julkisen avaimen esim. Tietokantojen perusteissa, pushauksen pitäisi toimia ja voit siirtyä seuraavaan kohtaan.

Pushaus ei toimi. Nyt kyse on siitä, että git haluaisi suorittaa julkisen avaimen autentikoinnin. Se ei kuitenkaan onnistu koska emme ole kertoneet gitille julkista salausavaintamme.

  • Luo salausavain antamalla komentoriviltä komento ssh-keygen
    • Voit vastata kaikkiin kysymyksiin enterillä
  • Syntyy kaksi salausavainta, salainen ja julkinen. Ne sijoitetaan kotihakemistosi alla olevaan hakemistoon .ssh
  • Mene hakemistoon ja katso hakemiston sisältöä
  • Tiedosto id_rsa.pub sisältää julkisen avaimen, se on tarkoitus kopioida githubiin jotta avaimeen perustuva kirjautuminen onnistuisi
    • Näet tiedoston sisällön komennolla cat id_rsa.pub
  • Anna komentoriviltä komento ssh-add
  • Mene GitHubin asetussivulle klikkaamalla oikean yläkulman symbolista ja valitsemalla settings
  • Valitse settingseistä SSH and GPG keys
  • Luo uusi SSH-avain
    • Anna avaimelle joku title (esim. laitos) ja kopioi tiedoston id_rsa.pub sisältö kohtaan key
  • Suorita uudelleen git push:
mluukkai@melkki:~/ot-harjoitustyo$ git push
Counting objects: 3, done.
Writing objects: 100% (3/3), 213 bytes | 106.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote:
remote: Create a pull request for 'master' on GitHub by visiting:
remote:      https://github.com/mluukkai/ot-harjoitustyo/pull/new/master
remote:
To github.com:mluukkai/ot-harjoitustyo.git
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.

Nyt kaikki näyttää toimivan.

Tehtävä 14: Lisää tiedostoja

  • Tee juuri luodun repositorion sisälle hakemisto laskarit
    • Ja sen sisälle hakemisto viikko1
    • Komentorivitehtävien lopussa oli kehotus: Mene tämän jälkeen kotihakemistoon ja anna komento tree kurssit. Copypastea komennon tulostus talteen, tarvitset sitä myöhemmin
    • Tee hakemiston laskarit/viikko1 sisälle tiedosto komentorivi.txt ja kopioi sinne komennon tree tulos
    • Edellisen tehtäväsarjan lopussa kehoitettiin tallentamaan harjoitusrepositoriossa annetun komennon git log --stat | cat tulos
    • Tee hakemiston laskarit/viikko1 sisälle tiedosto gitlog.txt ja kopioi sinne githarjoittelun tulos
  • Kirjoita jotain tekstiä hakemiston juuressa olevaan tiedostoon README.md
    • Muotoile tekstisi markdown-notaatiota käyttäen
    • Tee tiedostoon esim. jokin otsikko, tavallista tekstiä, joka sisältää lihavoituja ja kursivoituja osuuksia
    • Näemme pian tekstin ruudulla muotoiltuna
  • Commitoi muutokset
    • Muista aina commitoinnin yhteydessä lisätä tiedosto/muutokset commitoitavaksi
  • Pushaa koodi githubiin komennolla git push

Tehtävä 15: Tiedostot GitHubissa

  • Mene GitHub-repositoriosi sivulle
    • Käytännössä tämä tapahtuu uudelleenlataamalla repositorion luomisen jälkeen avautunut sivu
  • Huomaat että tiedostot näkyvät nyt repositorion sivulla. Sivulle renderöityy repositorion juuressa olevan README.md:n sisältö markdown-muotoiltuna
  • Voit editoida repositoriossa olevia tiedostoja suoraan GitHubin editorilla menemällä tiedoston sivulle ja painamalla kynäsymbolia
  • Tee README.md:hen linkit repositorion hakemistossa laskarit/viikko1/ oleviin tiedostoihin komentorivi.txt ja gitlog.txt
    • Ohje linkin muodostamiseen löytyy täältä
    • Tiedostojen urlin saat navigoimalla GitHubissa tiedostoon ja kopioimalla osoitteen selaimen osoiteriviltä
  • Repositoriosi tulee näyttää suunnilleen seuraavalta

Jos teit kaiken oikein, pääset README.md:ssä olevia linkkejä klikkaamalla näkemään linkitettyjen tiedostojen sisällön.

Paikallisen repositorion ajantasaistaminen

  • GitHubissa tekemämme muutokset ovat tehneet etärepositorioon uuden commitin
  • Etärepositorio on nyt edellä paikallista repositorioamme
  • Saamme tuotua muutokset paikalliselle koneelle komennolla git pull
  • Kokeile komentoa ja varmista, että muuttunut sisältö on nyt paikallisessa repositoriossa

Tehtävä 16: Lisää GitHubia

  • Tee paikallisella koneella jokin muutos esim. tiedostoon README.md
  • Lisää ja committaa muutos
  • Vie muutokset GitHubiin komennolla git push
  • Varmista GitHubista että muutokset näkyvät
  • Paikallinen repositoriosi ja GitHubin etärepositorio ovat jälleen samassa tilassa.

Tehtävä 17: Paikallisen ja etärepositorion epäsynkrooni

  • Joskus käy niin, että paikallinen ja etärepositorio menevät epäsynkroniin, siten että molempiin tehdään yhtäaikaa uusi commit
  • Luodaan tälläinen tilanne
  • Tee paikalliseen repositorioon muutos tiedostoon README.md, lisää ja committoi muutos
    • Älä pushaa muutosta GitHubiin
  • Tee GitHubiin muutos johonkin muualle kuin README.md-tiedostoon
    • editoi siis esim. tiedostoa gitlog.txt hieman suoraan GitHubissa
  • Yritä nyt pushata paikallisen repositorion muutokset githubiin
  • Seurauksena on virheilmoitus
mluukkai@melkki:~/ot-harjoitustyo$ git push
To git@github.com:mluukkai/ot-harjoitustyo.git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'git@github.com:mluukkai/ot-harjoitustyo.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
mluukkai@melkki:~/ot-harjoitustyo$
  • Tulet törmäämään tähän varmaan useasti jatkossakin.
  • Ongelma ei ole paha. Koska paikalliset ja GitHubin muutokset ovat kohdistuneet eri tiedostoihin, selviämme helpolla
  • Ensin pullaamme muutokset paikalliseen repositorioon komennolla git pull
  • Saat suurella todennäköisyydellä seuraavan ilmoituksen
hint: You have divergent branches and need to specify how to reconcile them.
hint: You can do so by running one of the following commands sometime before
hint: your next pull:
hint: 
hint:   git config pull.rebase false  # merge (the default strategy)
hint:   git config pull.rebase true   # rebase
hint:   git config pull.ff only       # fast-forward only
hint: 
hint: You can replace "git config" with "git config --global" to set a default
hint: preference for all repositories. You can also pass --rebase, --no-rebase,
hint: or --ff-only on the command line to override the configured default per
hint: invocation.
fatal: Need to specify how to reconcile divergent branches.
  • Git kysyy millä tavalla sen pitäisi käsitellä kahden eri branchin eli “koodihaaran” yhdistämistilanne, tässä tapauksessa branchit ovat paikallisen koneen versio ja GitHubissa oleva versio (ks. halutessasi täältä lisää vaihtoehtojen eroista)
  • Valitaan ylin, eli annetaan komento git config pull.rebase false
  • Tehdään nyt uudelleen git pull
    • Pullaaminen synnyttää ns. merge commitin, jolle joudumme määrittelemään commit-viestin avautuvaan editoriin
    • Oletusarvoinen viesti käy, eli riittää että poistut editorista tallentaen muutokset
  • Ja pushaamme ne uudelleen githubiin
  • Nyt paikallinen ja etärepositorio ovat taas synkroonissa
  • Katso repositorion tilaa nyt komennolla gitk
  • Näet, että repositorion uusimmalla commitilla on nyt kaksi edeltäjää, paikallinen commit ja etärepositorion commit

alt text

Jos muutokset olisivat kohdistuneet samaan tiedostoon, olisi syntynyt hieman vakavampi tilanne, eli merge-konflikti. Konfliktit on pakko selvittää itse editorin avulla. On toki olemassa työkaluja, mergetooleja, jotka auttavat konfliktin selvittämisessä. Emme kuitenkaan mene tällä kurssilla merge-konflikteihin.

Nyrkkisääntönä kannattaa pitää aina sitä, että kun rupeat työskentelemään paikallisessa repositoriossa, pullaa ensin kaikki muutokset etärepositoriosta. Ja kun lopetat työskentelyn, pushaa muutokset etärepositorioon. Näin konflikteja ei yhden ihmisen työskentelyssä todennäköisesti tule.

Lisää gitiä

Gitin peruskäyttö tulee varmasti tutuksi kurssin aikana. Gitin edistyneempien piirteiden opiskelua kannattaa ilman muuta jatkaa myös omin päin. Internetistä löytyy suuri määrä enemmän tai vähemmän hyviä tutoriaaleja. Seuraavassa muutama linkki

Labtool

Rekisteröi nyt omat tietosi ja luomasi repositorio Labtooliin.