GIT

Sissejuhatus

giti eelis on eelkõige hierarhiline arendus, näiteks linuxi kernel kus siis erineva tasemega üle maailma kommitivad ja siis kõvemad vaatavad nõrgemate koodi üle ja nii liiguvad patchid järjest ülespoole välja kuni lõpuks jõuavad järgmisse linuxi versiooni. Seega on ta sobilikum suurte opensource projektide jaoks kus erinevad commit levelid. Väikestes asutustes kus peamiselt lisatakse trunci tasuks kaaluda pigem subversioni kasutamist.

Head omadused

• Jagatud versioonihaldus
• Revisioon – SHA1 kontrollsumma
• Snapshotid, mitte Erinevused
• .git kaust - täielik ajalugu
• Kõik tegevused kohalikud (peaaegu)
• Olemas diktaatorid ja leitlandid kes kinnitavad muudatusi

Paigaldamine

TODO

Repode tekitamine ja kasutamine

Uue repo saamiseks

$ cd /srv/git/base
$ git init --bare --shared tarkvara.git

Mille tulemusel tekib

git@git.zoo.tartu.ee:base/tarkvara.git

Võtmete tegemine, masinas kus soovime kasutada giti anname käsu

$ ssh-keygen -t dsa 

See tekitab kasutaja .ssh kausta kaks faili id_dsa privaatse ja id_dsa.pub avaliku võtme

Ligipääsemiseks tuleb logida serverisse kus git töötab ja lisama oma avaliku võtme git kasutajale:

# cat id_dsa.pub >> /srv/git/.ssh/authorized_keys

Seejärel saab juba oma suvalises GIT repositooriumis lisada selle asukoha oma repole:

$ git remote add origin git@git.zoo.tartu.ee:base/tarkvara.git

Ja lükata oma muudatused üles:

$ git push origin master

Kasutamiseks käsurealt

$ git clone git@git.zoo.tartu.ee:base/tarkvara.git

Tehtud muudatused committida ja siis pushida keskserverisse:

$ git add fail1 fail2 fail3
$ git commit -m "kirjeldus"
$ git push origin master

Probleemid

Kui keegi on origin/masterit juba muutnud, peale seda, kui sa viimati sealt tõmbasid, seega:

$ git pull origin master

Kui öeldakse pullimisel, et tekkis konflikt (st sina ja keegi teine on täpselt sama kohta muutnud), siis peaks git nimetama ka failid ja siis nendes failides on üks või mitu konflikti kohta, mis on markeeritud nii:

<<<<<<
# Sinu kood
========
# Uus kood, mis tuli pullimis

Nüüd pead hoolega lugema ja vaatama, mis osa tuleb alles jätta ja mis kustutada või on hoopis mõistlik kombineerida kahest kokku.

Konfliktsed failid pead pärast parandamist uuesti addima ja committima.

Siis saad jälle pushida.

Lisakäske

Kohalikud tegevused

• git checkout bug23

Kaugtegevused

• git pull origin
• git push origin

Harude võrdlus - SVN

svn cp svn://svn.server.ee/projekt/trunk svn://svn.server.ee/projekt/branches/3.5
svn sw svn://svn.server.ee/projekt/
svn ci -m „muudatus 3.5-s“
svn sw svn://svn.server.ee/projekt/trunk
svn merge -c 123 svn://svn.server.ee/projekt/
svn ci -m „r123 mergetud 3.5-st“

Harud - GIT

git co -b 3.5
git push origin 3.5
git ci -m „muudatus 3.5-s“
git co master
git merge 3.5
git push origin

Ühistöö

Lingid

Huvitav jubin nimega Gource võimaldab versioonihalduse ajalugu visualiseerida:

PS. Abiks raamat: http://progit.org/book/