Difference: LinuxToolsGit (5 vs. 6)

Revision 62013-05-15 - ljleppan

Line: 1 to 1
 
META TOPICPARENT name="LinuxTools"

Git-versiohallintaohjelmiston käytön alkeita ja käyttötilanteita

Line: 62 to 62
 

GIT ja leksikkoprojektit (LEO)

Added:
>
>
Leksikkoprojektit ovat perusluonteeltaan hyvin samankaltaisia muiden ohjelmointiprojektien kanssa. Molemmissa käsitellään tiedostoja, joissa yhdekin merkin tai rivin muutoksilla on usein suuria muutoksia lopputuloksen toiminnallisuuden kannalta. Tästä syystä GIT - tai jokin muu versiohallintajärjestelmä kuten SVN - on luonnollinen valinta kehityksen apuvälineeksi. Yhden kehittäjän tapauksessa GIT mahdollistaa muutosten seurannan ja aiempiin versioihin palaamisen. Useamman kehittäjän projekteissa GIT helpottaa huomattavasti hajautettua kehitystä ja auttaa välttämään hajautetun kehityksen yleisimpiä sudenkuoppia.

Versionhallinnan hyvät toimintatavat leksikkoprojekteissa

Samoin kuin muussa versionhallintaa käyttävässä kehitystyössä, tulee leksikkoprojekteissakin käyttää hyväksi todettuja toimintatapoja versionhallinnan suhteen.

Versionhallinnasta löytyvien versioiden tulisi olla aina toimivia kokonaisuuksia. Ohjelmointiprojekteissa nyrkkisääntö on, että versionhallinnasta löytyvän version tulee aina kääntyä ilman virheitä. Tämä ei tarkoita sitä, ettei versionhallintaan saa commitoida mitään jollei se ole täysin valmis. Tärkeätä kuitenkin on, että versionhallintaan puskettu uusi työsarka ei riko mitään olemassaolevaa ja ennen kaikkea joku muu voi jatkaa työskentelyä saman tiedoston kanssa ilman, että hänen täytyy tehdä mitään omaan työsarkaansa liittymätöntä sinun muutoksillesi.

Versionhallinnan committien tulee vastata mahdollisia muutostarpeita. Jokaisen commitin tulisi olla vain yksi muutos. Hyviä nyrkkisääntöjä ovat muunmuassa seuraavat: "Jos sen voi jakaa pienempiin osiin, se on liian iso" ja "Jos se sisältää sanan 'ja', se on liian iso". Esimerkiksi commit jonka kommenttina on "muokattu ellatiivin ja ablatiivin käsittely' i-päätteisillä juurilla" on huono. Jos myöhemmin todetaan että ellatiivin käsittelytapa on huono, ei siihen tehtyjä muutoksia voida vetää takaisin vaikuttamatta samalla ablatiivin käsittelyyn. On siis parempi tehdä kaksi erillistä committia.

Aina commitin liian suuri laajuus ei ole aivan yhtä selvää. Tarkastellaan tilannetta jossa kehittäjä muokkaa LEXC-tiedostoon uuden käsittelypolun ellatiiveille ja liittää sen jo olemassa olevaan rakenteeseen. Commit-kommentin voisi ajatella olevan "Lisätty ellatiivin käsittely". Yksi konkreettinen asia, kaikki on siis kunnossa, eikö? Väärin. On tehty kaksi muutosta: (1) lisätty ellatiivit käsitteleviä rivejä ja (2) integroitu ellatiivien käsittely olemassa olevaan rakenteeseen. On parempi toteuttaa muutostyö kahtena eri committina: toisessa lisätään ellatiivit käsittelevät rivit itsenäisenä kokonaisuutena joka ei vaikuta mitenkään projektin toiminnallisuuteen (poislukien foman antama "käyttämätön leksikko" -varoitus) ja toisessa integroidaan ellatiivien käsittely muuhun rakenteeseen. Mikäli myöhemmin huomataan että ellatiivinkäsittelyn lisääminen on rikkonut projektin, on yhden commitin tapauksessa metsästettävä virhettä kahdesta eri paikasta: itse ellatiivit käsittelevät rakenteesta ja toisaalta sen muuhun rakenteeseen integroivasta osasta. Mikäli työ on puskettu kahtena eri committina, voidaan virhe helposti rajata vain toiseen näistä sijainneista.

Älä uudelleenkirjoita historiaa. Versionhallinnan koko kantava ajatus on vanhojen versioiden säilyttäminen. Historian uudelleenkirjoittaminen vanhoja committeja muuttamalla tai poistamalla on huono tapa, eikä sille ole juuri koskaan mitään todellista tarvetta. Poikkeuksen muodostavat vain tapaukset joissa pusket vahingossa repositorioon omat verkkopankkitunnuksesi.

Leksikkoprojektien uniikit haasteet

GIT:n käyttö on helpointa ja vaivattominta projekteissa ja tilanteissa, joissa käsiteltäviä tiedostoja on suurehko määrä suhteessa kehittäjien määrään. Pienessäkin olio-pohjaisessa Java-projektissa saattaa helposti olla kymmeniä tai satoja luokkia, joista jokainen on omassa tiedostossaan ja omaa oman uniikin ja muista erillään olevan toiminnallisuutensa. Täten kukin kehittäjä työskentelee kerrallaan muutaman pienen itsenäisen tiedoston kanssa ja tilanteet joissa useampi kehittäjä haluaa samaan aikaan muuttaa samaa tiedostoa ovat harvinaisia.

Mikäli kuitenkin tarkastelemme pientä leksikkoprojektia, on projektin tiedostomäärä todennäköisesti pienehkö suhteessa kehittäjien määrään. Jo pienessä kahden kehittäjän LEXC-projektissa on hyvinkin todennäköistä että lähes jatkuvasti molemmat kehittäjät haluavat muuttaa jotain samasta tiedostosta. Tällaiset tilanteet hankaloittavat versionhallintaa, sillä muutoksia täytyy yhdistää jatkuvasti, mikä puolestaa syö kehitysaikaa. Toisaalta versionhallinnan käyttämättä jättäminen on harvoin vaihtoehto, sillä se pelastaa projektin niin valtavalta määrältä muita harmeja ja hidastuksia.

Leksikkoprojekteissa saattaakin olla siis paljon tarvetta ja käyttöä GIT:n commit käskyn -p -vivulle, jonka avulla voidaan luoda committeja tiedoston osista kokonaisten tiedostojen sijaan.

Versionhallintaa tukevat työkalut leksikkoprojekteissa

Samoin kuin muissa hajautetun kehityksen projekteissa, myös monen kehittäjän leksikkoprojekteissa on tärkeää ylläpitää tietoa siitä kuka työskentelee minkäkin projektin osa-alueen kimpussa, mitä on tehty ja mitä vielä tarvitsee tehdä. Tässä auttavat mm. GITHubin repositoriokohtainen wiki sekä Issue ja Milestone -työkalut.

Eräs hyvä toimintamalli on luoda GITHubin repositorioon oma kategoria (Label) tekemättä oleville tehtäville, johon lisätään kaikki TODO-listan kohdat itsenäisinä tehtävinä. Tällöin kehittäjä voi merkitä omakseen tietyn tai tiettyjä tekemättä olevia tehtäviä, ja vältytään tilanteilta joissa useampi ihminen tekee samaa asiaa toisistaan tietämättä. Tehtäviä voidaan myös yhdistää merkkipaaluiksi (Milestone), jolloin projektin kehityksen seuraaminen helpottuu ja projektin aikatauluttaminen on helpompaa: voidaan esimerkiksi asettaa tavoitteeksi, että tietyt merkkipaalut on saavutettu tiettyyn päivämäärään mennessä.

Issue-työkalulla voidaan myös hallita helpommin projektin bugeja: Jos kehittäjä A huomaa oman työnsä ohessa että leksikkoprojekti käsittelee tietyn kehittäjän B työsarkaan kuuluvan sanan väärin, on helppoa ja nopeaa tehdä asiasta Issue. Tällöin löydetystä bugista jää dokumentti, eikä se unohdu sähköpostin syövereihin tai työpöydän sadan muun Post-It -lapun sekaan. Myös muut parannusehdotukset hoituvat helpommin samalla tavoin toimimalla.

GITHubin wikissä taas tarjotaa helpon ympäristön koordinoida projektia vapaamuotoisemmalla tekstiaineistolla.

Mikäli projektisi ei ole GITHubissa vaan jossain muualla, on tärkeää varmistaa että projektin ja tehtävien dokumentointi hoidetaan jollain muulla tavoin. Yksinkertaisimmillaan tämä onnistuu esimerkiksi GoogleDocs -palveluun luodulla taulukolla jossa on listattuna kaikki projektin tehtävät, kenen vastuulla ne ovat ja ovatko ne tekemättä, työn alla vai valmiina.

 

Harjoitus

1. Hipulla on toimiva git-ohjelmisto asennettuna. Kokeile tutoriaalien perusteella luoda omasta harjoitustyöstä GIT-versioarkisto. Onnistuiko tämä ohjeiden mukaan ja tuliko vastaan ongelmia, mitä?

 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback