Difference: LinuxToolsGit (7 vs. 8)

Revision 82013-05-16 - ljleppan

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

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

Line: 68 to 68
  Samoin kuin muussa versionhallintaa käyttävässä kehitystyössä, tulee leksikkoprojekteissakin käyttää hyväksi todettuja toimintatapoja versionhallinnan suhteen.
Changed:
<
<
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.
>
>
Versionhallinnasta löytyvien versioiden tulisi olla aina toimivia kokonaisuuksia. 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. Ohjelmointiprojekteissa nyrkkisääntö on, että versionhallinnasta löytyvän version tulee aina kääntyä ilman virheitä. Ajatusta kuvaamaan sopii hyvin partiolaisten leiripaikkoja koskeva sääntö: leiripaikka jätetään parempaan kuntoon kuin se oli tultaessa. Samalla tavoin repositorioon puskettavan uuden version tulee olla paremmassa kunnossa kuin sieltä työskentelyn alussa noudettu. Joko sitä on yleisesti siistitty, tai sitten se sisältää kaiken vanhan ja edelleen toimivan toiminnallisuuden lisäksi jotain uutta toiminnallisuutta. Vaikka olisitkin lisännyt jotain toiminnallisuutta, ei sillä ole mitään merkitystä jos seuraava kehittäjä joutuu käyttämään ennen oman työnsä alkua tunnin sinun rikkomiesi asioiden korjaamiseen.
  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.
Line: 76 to 76
  Ä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.
Added:
>
>
Varsinkin julkisten repositorioiden tapauksessa tuntee kehittäjä monesti tarvetta ylläpitää kuvaa siitä, että hän tekee vain hyvää lopputulosta: siirrytään suoraan tyhjästä lopulliseen ja hyvään. Tämä "tehdään kaikki lokaalisti ja pusketaan vain täydellistä" -menettely on kuitenkin yleisesti ottaen huono ajatus. Säilyttämällä versionhallinnassa erilaisten iteraatioiden muodossa historian siitä miten jokin projektin osa on kehittynyt, voidaan samaa prosessia tarkastella myöhemmin esimerkkinä: "Yritettiin viimeksi X, Y ja Z, mistä X ja Z ei toimineet". Ilman virheiden ja harha-askelten dokumentointia unohtuvat virheet helposti. Kun virhe unohtuu, se toistetaan. Ja täten on aivan suotta tehty useaan otteeseen samaa virhettä monta kertaa ja menetetty kallisarvoista kehitysaika nelikulmaisen pyörän uudelleenkeksimiseen.
 

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.

Line: 92 to 94
  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ä.
Added:
>
>
Jos projektin tarkoitus on esimerkiksi taivuttaa suomen nomineita niiden sijassa ja luvussa, löydetään heti luonnollisia Tehtäviä sijamuodoista ja luvuista. Tehdään jokaiselle sijalle nominin molempia lukuja varten oma tehtävä, jonka kehittäjät voivat merkitä omakseen. Tällöin työnjako tapahtuu käytännössä itsestään ja samalla saadaan hyvää tietoa projektin etenemisestä. Pienessä esimerkissämme merkkipaaluja voisivat olla "Kaikki monikon sijat" ja "Kaikki yksikön sijat".
 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.

 
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