Miks mul on tarvis hajusat versioonikontrolli süsteemi?

Esiteks tuleb hajusa versioonihalduse juures aru saada sellest, et sa ei jää ilma millestki, mida pakuvad tsentraliseeritud süsteemid. Sa võid luua samamoodi keskse repositooriumi, kuhu kõik saavad oma muudatusi üles lükata ning teiste muudatusi alla tõmmata. Erinevus on selles, et Subversioni puhul see ongi su ainuke valik.

Et ma peamiselt tunnen Giti, siis järgnevalt just Giti eelistest, mis võivad aga ei pruugi kehtida kõigile hajusatele versioonihaldustele...

Gitiga tulevad varukoopiad kauba peale kaasa. Sa ütlesid, et keskserveri eelis on see, et see tõenäoliselt backupitakse. Kuid hajusa süsteemi puhul polegi erilist vajadust mingit eraldi varundamist sisse viia, kuna varukoopia kesksest repositooriumist on nagunii iga arendaja masinas olemas. Ning nagu me teame, siis paljudes ettevõtetes Subversioni repositooriumi tõenäoliselt ei backupita.

Giti repositooriumi loomisega saab hakkama isegi sülelaps. Ütleme, et alustad väikse prototüübi loomist. Selle peale kulub ehk paar-kolm päeva. Nagu igasuguse koodi puhul nii oleks ka prototüübi puhul hea kasutada versioonihaldust, eriti kui sa tahaks proovida läbi erinevaid variante. Kuid kas sa viitsid selle väikse asja jaoks kesksesse serverisse uue repositooriumi luua? Või paluda serveri adminil see luua? Tõenäoliselt mitte. Hajutatud versioonihalduse puhul seda küsimust ei kerki - on ilmelihtne lüüa oma prototüübi kataloogis sisse käsk git init ning uus repositoorium ongi olemas, sealsamas kataloogis.

Git muudab igaveseks sinu ettekujutust sellest mida branchimine tähendab. Subversionis pead sa uue haru loomiseks tegema midagi sellist:

cd myproject
svn cp http:///myproject/trunk http:///myproject/branches/mybranch
cd ..
svn co http:///myproject/branches/mybranch
# ...oota mitu minutit...
cd mybranch

Gitiga käib branchimine nõnda:

cd myproject
git branch mybranch
git checkout mybranch  # ...toimub hetkeliselt...
# alusta tööd uue branchi kallal siinsamas kataloogis
# tee mitu committi, seejärel lülitu tagasi põhiharule
git checkout master # ...jällegi hetkeliselt...
# kogu su kataloogi sisu on nüüd selline nagu põhiharus

Seega Gitiga võid branchida mitu korda päevas, mitu korda tunnis, nii palju kui süda lustib. Ning branchide vahel lülitamine käib ülimugavalt.

Git saab ise aru, millised failid on ümber nimetatud, kopeeritud, kustutatud. Subversionile pead seda kõike aga ise konkreetselt ütlema. Näiteks nõnda:

svn mv Foo.c Bar.c
svn rm OldFoo.c
svn cp Template.c New.c
svn ci

Giti puhul sa lihtsalt kustutad, nimetad ümber ja kopeerid nii nagu sa normaalselt teeksid ja siis lihtsalt:

git add --all # juhul kui on tarvis uusi faile lisada
git ci -a

DVC eelis tekib just siis, kui tegemist on suurte projektidega. DVC võimaldab tekitada keerulisemaid skeeme kuidas nö. koodi läbivaadatakse (näiteks miks Linux GIT-i kasutab).

Samuti lokaalsed ja enda eksperiment branchid on väga sõltuvust tekitavad. (Vahel on olukordi kus on endal 7 või rohkem isiklikku branchi.)

Samuti tundub, et hg, git ja bz oma olemuselt 'branch merge'-mise paremini läbi mõelnud. Kuna seal on just soodustatud isiklikud ja eksperimentaalsed 'branch'-id, siis peab neid olema ka kerge kokku sobitada.

Mergemise headusest git-i näitel:

Ütleme, et mitu erinevat inimest töötavad ühe mingi projekti ja on mitu erinevat uut asjandust tulemas projekti. Igal featuuril on oma branchid

 git branch feature-a master
 git branch feature-b master
 git branch feature-c master
 git branch feature-d master

Siis sul on veel mingid fix branchid

 git branch fix-func-a master
 git branch fix-func-b master

Ning mingil hetkel, näiteks päeval lõpus... öeldakse, et feature-a ja feature-b, et nende kood üsnagi toimib. Selleks, et testida, kas nende kood koos töötab, ning kõike kokku proovida tuleb teha lihtsalt.

 git branch alpha master
 git co alpha
 git pull . feature-a feature-b fix-func-a fix-func-b

(parimal juhul ei tule käsitsi midagi merge-da, git teeb kõik ise... ainult sel juhul tuleb seda ise teha, kui kahes branchis on samu koodi ridu muudetud... loomulikult kaasneb automaatse merge-ga mõned ohud...)
nüüd kui kõik branch alpha on testitud:

git co master
git pull . alpha
git branch -d alpha feature-a feature-b fix-func-a fix-func-b

Selle lõpuks on sul olemas ainult branchid master, feature-c, feature-d. Loomulikult on olemas kogu history iga eelneva branchi kohta.

Midagi taolist toimub linux-kernel-i arendamisel. Kuna paljud arendavad oma osasid, siis tuleb sellist ühist mergemist päris palju. (26-branchi näiteks korraga mergeda).

Ühe põhjuse võib siia kohe lisada: arendajad saavad omavahel koodi jagada, ilma et see peaks keskrepositooriumist läbi käima. Näiteks võib tegemist olla mõne eksperimendiga või lihtsalt sooviga lasta teisel kood üle vaadata.

Kui nüüd Sinu esimese põhjenduse juurde minna, siis on nii et kui tegemist on vähegi suurema projektiga (pean silmas koodi mahtu, arendusperioodi pikkust, tiimi suurust), siis mõte sellest, et iga arendaja teeb SVNi muudkui uus harusid endale ei tundugi korraga üldse nii hea enam.

Kõvaketta õhku lendamise või varastamise oht ju muidugi on, kuid sa ju ometi teed varukoopiad teistest olulitest asjadest, mis sul läpaka kõvakettal on? Seega võib lokaalse repositooriumi ka sinna varundatavate asjade hulka lisada ja see maandab kadumamineku riski kohe üsna olulisel määral.

Ja kui nüüd spetsiifilisemaks minna ja rääkida näiteks git-ist, siis lisaks sellele, et ta on hajussüsteem, annab ta juurde ka mõned võimalused, mis oma olemuselt ei ole üldse hajusad, aga mis SVNiga lihtsalt võimatud on - minu lemmik on näiteks see, et git jälgib "teksti", mitte faile. Kui refaktoorid oma koodi ühest failist teise, siis git teab kust see tulnud on. Ja see on teinekord üks äraütlemata kasulik teadmine.