Versionhallintahistorian roskautumisen välttäminen



Jatkona Teemun kirjoitukseen versionhallinnan vajaakäytöstä:

Ohjelmiston kehitys tapahtuu usein kiemuroiden kautta: kokeillaan jotain, jota myöhemmin joudutaan korjaamaan, ja tehdään ajoittain myös yksinkertaisempia virheitä joita pitää oikaista. Nämä kiemurat lisäävät kohinaa versionhallintahistoriaan: versioiden määrä kasvaa ja loogiset muutokset levittyvät usean version yli. Selkeämpää olisi jos versioita olisi vähemmän ja ne vastaisivat loogisia kokonaisuuksia.

Git (ja muut hajautetut versiohallintajärjestelmät vastaavilla tavoilla) sallii seuraavan sarjan komentoja, jolla voi muuttaa juuri tallennettua versiota:

[muutoksia tiedostoihin]
$ git commit -m "Muutoksia."
[korjauksia viime muutokseen]
$ git commit --amend -m "Muutoksia, tällä kertaa oikein!"

Viimeinen komento ”–amend” -vivulla näennäisesti ylikirjoittaa edellisen version! Minkä takia tällaista sallitaan, ja milloin siitä on hyötyä? Nimenomaan kun halutaan vähentää versionhallintahistorian roskautumista, eli turhien versioiden lisäämistä. Kun kyse ei ole loogisesta muutoksesta, vaan korjauksesta edelliseen muutokseen, voi olla parempi päivittää aikaisemman version kuin lisätä uuden.

Miten versionhallintahistorian muokkaaminen (l. aikaisemman version ylikirjoittaminen) tällä tavalla voi onnistua? Hajautetuissa versionhallintajärjestelmissä commit ei enää tarkoita sitä, mitä se tarkoitti niitä edeltävissä keskitetyissä versionhallintajärjestelmissä (esim. CVS ja Subversion):

git commit = tallenna versio
cvs/svn commit = tallenna versio _ja_ julkaise

Julkaiseminen tarkoittaa tässä siis uuden version julkaisemista muille versionhallinnan käyttäjille. Tästä erosta seuraa että niin kauan kun muutos ei ole julkaistu, voidaan hajautetussa järjestelmässä hallitusti muuttaa paikallisen säiliön historiaa (ja sen jälkeen julkaista muutokset erillisenä askeleena ”git push” -komennolla).

Tämä mahdollisuus korjata jo tallennettuja versioita ennen kuin ne julkaistaan osoittautuu käytännössä hyvinkin hyödylliseksi: usein pieniä virheitä tulee tarpeen korjata juuri siinä viimeisessä versioissa.

Pitämällä versiot mahdollisimman yhtenäisinä versiohistorian seuraaminen ja muut versionhallintaoperaatiot helpottuu. Hajautetut versionhallintajärjestelmät auttavat versiohistorian roskautumisen välttämisessä tarjoamalla toiminnallisuutta kuin esim. ”git commit –amend” ja ”git rebase”.

Tämän artikkelin on kirjoittanut Markus Holmberg  ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Yksi kommentti artikkeliin ”Versionhallintahistorian roskautumisen välttäminen

  1. Tuot esiin hajautetun versionhallinnan mielestäni ehkä oleellisimman edun:

    Muutoksien tallentaminen ja muutoksien jakaminen on erotettu toisistaan.

    Melkein mikä tahansa tiimi voi hyötyä tästä. Se mahdollistaa työtapoja jotka Subversionilla ovat käytännössä mahdottomia tai ainakin tolkuttoman työläitä. Spolsky kirjoitti hiljattain Mercurial-tutoriaalin jossa tuodaan juuri näitä pointteja esiin.

    Hajautetun versionhallinnan edut ovat kiistattomat. Jos nämä edut pitäisi summata yhteen sanaan niin se sana olisi “joustavuus”. Työkalut eivät vielä välttämättä ole kaikilta osin valmiita mainstream -käyttöön, mutta tämä puoli paranee koko ajan tasaista tahtia.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *