Bavite li se programiranjem, dizajnom ili nekim drugim kreativnim radom na računalu?
DVCS For The Win
Ukoliko je odgovor da, vjerojatno koristite neki sustav za rukovanje različitim verzijama vašeg uratka, pa makar to bili to direktoriji nazvani “novo”, “novije-2″, “staro-prošli-tjedan”. Moguće je da već i koristite neke od mnogobrojnih VCS / SCM sustava; no, podržava li sustav koji koristite i distibuiran rad?
Čak i ako sami radite na projektu i nitko nikada neće vidjeti ništa osim finalnog proizvoda, isplati se koristiti distribuirani sustav za verzioniranje projekta (DVCS – Distributed Version Control System) — osim jednostavnosti zbog toga što nije potrebno konfigurirati i spajati se na centralni repozitorij (čak i ako on bio na vašem lokalnom disku), DVCS-ovi vam pružaju nešto mnogo više, a to je puno, puno veća sloboda u eksperimentiranju na vašem projektu.
A kod kreativnog rada gdje možete imati mnogo draftova koje kombinirate, bacate u zaborav, vučete nazad iz ladice, slažete jedne preko drugih i na kraju dobijate konačan proizvod, ta sloboda u eksperimentiranju je ključna.
Što ne valja kod klasičnih sustava…
Kod klasičnih sustava (u koje spada i “kreiram-backup-direktorije-svako-malo” ad-hoc pristup), princip čuvanja verzija je linearan. Imate neku početnu verziju vašeg uratka, napravite promjene na njoj i kad ste zadovoljni pospremite novu verziju negdje na sigurno (npr. commit na server ili novi backup dir). Ukoliko kasnije saznate da ste nešto zeznuli, uvijek se možete vratiti na raniju spremljenu verziju, odnosno imate beskonačni undo.
Ali, jednom kada se vratite u prošlost (odlučite da novija verzija ne valja) i krenete drugim smjerom (kreirate novu granu projekta), praktički ste prisiljeni baciiti sve načinjene promjene u smeće, čak i ako dio njih još uvijek ima smisla. U teoriji vi možete iz zadnje verzije izvući dio promjena koji želite sačuvati i onda to primjeniti na novu granu. U praksi, svatko tko je radio netrivijalne SVN mergeove ili ručno kopirao izrezani dizajn i onda prepravljao da paše po drugom layoutu zna da to nije nimalo zabavan posao. U praksi, vi ručno morate napraviti posao koji bi VCS trebao moći napraviti za vas.
Zbog toga, najčeće se commitovi rade jednom kad ste prilično sigurni da je stvar ono što bi htjeli da bude. Rezultat toga je da se commit više koristi kao checkpoint, tj. pamti se trenutak u kojem je draft u “dobrom stanju”. Odnosno, promjene imeđu commitova su velike i često uključuju detalje koji nemaju nužno veze jedni s drugim, ali ste ih mijenjali u istom vremenskom periodu pa su eto završili zajedno.
… i kako distribuirani sustavi to popravljaju
Za razliku od toga, DVCS-ovi počinju od pretpostavke da postoji puno različitih grana u kojima se projekt neovisno razvija (jedan developer ima bar po jednu granu na kojoj on ili ona radi). Zbog toga si DVCS-ovi daju mnogo truda da osiguraju da se promjene jednog developera mogu jednostavno i sigurno kombinirati sa promjenama drugih, odnosno da se različite grane projekta mogu na siguran način mergeati.
Kako bi to osigurali, DVCS-ovi traže što manje promjene iz commita u commit, jer su male promjene puno manje ovisne o globalnom stanju u kojem je vaš projekt – ovise samo o nekoliko “susjednih” stvari (npr. nekoliko linija ispred i iza promjene u programskom kodu). Na taj način i developere “tjeraju” da promjene spremaju što ćešće i da međusobno neovisne promjene spremaju u različitim committovima.
Isto vrijedi i za vas kao solo developera na projektu. Filozofija DVCS-a je da za svaku ideju u projektu imate po jednu granu, u kojoj onda promjene nižete u puno commitova od kojih svaki sadrži malu promjenu. Ukoliko imate nekoliko stvari (ili alternativa iste stvari) na kojima radite u isto vrijeme, imat ćete nekoliko grana u repozitoriju. Ukoliko se tijekom razvoja pokaže da bi vam u jednoj grani dobro došle promjene koje ste već napravili za drugu granu, jednostavno “povučete” dotične commitove i automatski primjenite njihove promjene.
Odnosno, kod DVCS-ova grane projekta (branches) preuzimaju ulogu koju kod klasičnih VCS-ova imaju committovi. DVCS-ovi comittovi su, pak, dovoljno mali da ih je puno lakše preslagivati i kombinirati — ukoliko i dođe do konfliktalakše je izolirati problem i popraviti ga.
Kako organizirati repozitorij
Ukoliko ste novi u korištenju DVCS-a (ili čak klasičnih VCS-ova), sve ovo vam vjerojatno zvuči prilično zakomplicirano. Evo nekoliko općenitih savjeta kako jednostavno organizirati repozitorij za solo rad:
Za trenutni “dobar” draft (stanje s kojim ste zadovoljni i koje dalje nadograđujete – ono što biste zadnje skopirali u backup direktorij da sve to radite ručno) obično se koristi zasebna grana zvana master. Master je dakle početna točka za promjene koje radite.
Za svaku ideju, dodatak funkcionalnosti, bugfix, alternativu …., koju planirate, otvorite novu granu u kojoj ćete raditi samo na tome. Grana se kreira “grananjem” od mastera. Nakon što napravite par promjena u grani, ona će imati nekoliko comittova više od mastera (tj. sve comittove od prije + par novih koje ste napravili).
Kad ste zadovoljni sa promjenama koje ste napravili (npr. napisali ste i istestirali bugfix za vaš kod), granu spajate nazad u master, tj radite merge. Sustav će to napraviti tako da će uzeti sve comittove koji postoje u vašoj grani i redom ih zalijepiti na master. Ukoliko dođe do konflikta, trebat ćete popraviti samo zeznuti commit.
Da biste minimizirali mogućnost konflikta, trebate samo paziti na nekoliko stvari: da pojedini committovi budu što manji (i stoga što manje ovisini o ostatku koda), da pojedine grane ne rade promjene na istom mjestu (odnosno, ako rade, da koriste isti commit a ne zasebne committove za istu stvar) te da razlika između pojedine grane i mastera bude što manja.
Ovo zadnje zvuči kontra-produktivno – koji je smisao grane ako se ne smije (mnogo) razlikovati od mastera? Ne brinite, dugovječne i velike grane su sasvim česta pojava. Nema nikakve opasnosti da grana ima mnoge committove kojih nema u masteru – kod mergea će se oni samo zalijepiti na mastera i gotovo. Problematični dio su committovi kojih ima u masteru, a nema u dotičnoj grani – ova situacija događa se kad imate više grana pa jednu mergeate u master – ostale grane nemaju committove koje je ta grana sadržavala.
Stoga, da bi se smanjila mogućnost konflikta, ili bar olakšalo njegovo rješavanje, u dugovječnim granama treba s vremena na vrijeme povući u granu nove committove koji su došli u master. To se obično naziva rebase, a radi se tako da se privremeno maknu svi committovi iz grane, povuku se nove stvari iz mastera, a na kraju se committovi iz grane vraćaju jedan po jedan. Na taj način dobija se efekt kao da je grana kreirana iz trenutnog mastera.
Napomena: terminologija i organizacija razlikuju se ponešto od sustava do sustava; npr. neki nemaju više grana u jednom repozitoriju nego je svaka grana repozitorij za sebe. Ali osnovna ideja i način rada isti je za bilo koji od DVCS-ova.
Za kraj, najava
Ako ste nakon svega ovog pomalo (ili malo više od malo) zbunjeni, ne brinite. Stvar u praksi nije toliko komplicirana kako se čini (a moguće da sam je i ja komplicirano objasnio, primam sugestije u komentarima :). Stoga ne propustite slijedeći post u kojemu ću proći kroz osnove korištenja DVCSa koristeći kao primjer git, vjerojatno najpopularniji distribuirani VCS.
kako to izgleda kad zakomplicirate stvari ;-)
1 komentar(a)