A verziókezelés alapjai – hogyan és miért alakult ki, mik a legalapvetőbb működési elvei?

Bármilyen szoftverfejlesztési projektbe kezdünk is, annak egyik legfontosabb velejáró eleme lesz valamilyen verziókezelő rendszer, ami nélkül a munka elképzelhetetlen. Alapvető igazság a szakmában, hogy a programozó és az adminisztráció nem mindig jó barátok, azonban fontos tudni, hogy a minőségi munkavégzés nem ér véget az utolsó kódsor beírásánál. Ahhoz, hogy valakiből igazán jó fejlesztő váljon, elengedhetetlen, hogy rendelkezzen verziókezelési ismeretekkel és hogy jól is tudja alkalmazni azokat.

Miért van szükség egyáltalán verziókezelő rendszerekre?

Elsőre azt gondolhatnánk, hogy a válasz pofonegyszerű: Természetesen azért, hogy bármikor vissza tudjuk állítani a projektünket egy korábbi verzióra, ha szükséges.

Valójában ennél sokkal több van mögötte. Verziókezelő rendszerek nélkül ugyanis kész káosz uralkodna egy-egy projekt fejlesztése közben. Követhetetlen lenne, hogy ki, mit, mikor és hogyan hajtott végre és ha kiderül, hogy valahol valaki hibázott, azonnal jönne az egymásra mutogatás. Ezenkívül bármennyire szeretnénk is azt hinni, hogy fejben tudjuk tartani mit miért csinálunk, ennek sosincs jó vége. Lehet, hogy adott pillanatban valami egyértelműnek tűnik, de néhány hét elteltével már arra se fogunk emlékezni, hogy egyáltalán mit csinál a kódunk, nem hogy miért pont úgy írtuk meg, ahogy. Ha ráadásul nem is egyedül, hanem csapatban dolgozunk, amire azért valljuk be elég nagy esély van, verziókezelő rendszerek nélkül egész nap csak azzal lennénk elfoglalva, hogy kiderítsük mit kódoltak le a kollégáink. Ezek alapján nem is arra kellene magyarázatot adni, hogy miért használjunk ilyen rendszereket, hanem inkább arra, hogy miért ne.

A verziókezelés történelmi háttere

Ahhoz, hogy megértsük a verziókezelés logikáját, nem árt tisztában lenni annak kialakulásával és az egyes rendszerek szűk keresztmetszeteivel, amik elvezettek a ma legelterjedtebb verziókezelő rendszer létrejöttéhez, a Git-hez.

A kezdetek: SCCS és CVS

Az IT szektor rohamos fejlődése miatt a 70-es évek elején jelentősen megnövekedtek a szoftverek méretei, komplexebbek lettek, ebből adódóan létrehozásuk sokkal időigényesebbé vált és nagyobb erőforrást, azaz több embert kellett biztosítani hozzájuk. A csapatmunkával és a növekvő igényekkel együtt járt, hogy már nem volt elég fejben tartani, vagy „papíron” (ekkor még Excel tábla sem létezett) követni, hogy éppen mi történik a projektünkkel. Mit csináljon hát ilyen helyzetben a fejlesztő? Természetesen ír magának egy programot, ami emlékezik helyette.

Ezzel 1972-ben megszületett az SCCS (Source Code Control System), ami a legelső verziókezelő szoftver volt. Kicsit elterjedtebb és ismertebb utódja a CVS (Concurrent Versions System), aminek legfőbb ismérve, hogy alkalmas volt párhuzamos verziókezelésre. Vagyis, ha a fejlesztő valamiért úgy dönt, hogy mégiscsak a 2 verzióval ezelőtti állapot volt a nyerő, akkor különösebb gond nélkül visszaállhat rá és onnan folytathatja a munkát. Nem elhanyagolható hátránya viszont, hogy nem tudta kezelni az állományok egymáshoz való viszonyát. De mit is jelent ez?

A következő állomás: SVN

Azzal valószínűleg már tisztában vagy, hogy egy szoftver egésze nem csak egyetlen fájlban íródik. Főleg akkor nem, ha több ember dolgozik rajta, de még ha egyedül dolgozik valaki, akkor is bonyolultságtól és mérettől függően akár többszáz különböző állományból is állhat. Ha egy verziókezelő nem képes arra, hogy ezeket az állományokat önálló egységként kezelje, akkor nem tudunk variálni különböző verziókkal például úgy, hogy „A” állományhoz a „B” állomány kettővel ezelőtti verziója fog tartozni. Ezt kiküszöbölendő jött létre 2000-ben az SVN (Subversion) verziókezelő, ami már nem az állományokat verziószámozta egyenként, hanem azt az produktumot, ami az egymáshoz tartozó állományokból született. Sajnos azonban ez sem volt tökéletes – bár mind a mai napig használják.

Felmerült ugyanis egy újabb probléma, ami a folyamatos és egyre nagyobb ütemben történő fejlődéssel együtt járt. A rendszer hátránya ugyanis az, hogy túl centralizált. Minden egyetlen központi helyen van tárolva, ami, ha éppen valamiért nem elérhető, akkor aznap senki nem tud dolgozni. Ezenkívül további hátránya, hogy mindenki, aki adott projekten dolgozik, ugyanabba az aktuális állapotba kényszerül kódolni. Ezt orvosolandó hozta létre Linus Torvalds a Git verziókezelőt 2005-ben.

A ma legelterjedtebb verziókezelő: Git

A Git verziókezelő rendszert próbáld meg úgy elképzelni, mintha létrehoznád a saját kis univerzumodat. Egy külön projektet a nagy projekten belül, ahol csak és kizárólag Te vagy az Úr. A Git támogatja a különböző elágazások készítését, aminek köszönhetően teljesen függetlenül dolgozhatsz a saját kódodon anélkül, hogy befolyásolna mi történt a központi repository-ban. Működési elvét tekintve a bevett szokás, hogy minden egyes funkciónak külön branch-et (leágazást) készítenek és amikor a fejlesztő úgy gondolja, hogy készen van vele, akkor küld egy merge request-et, amivel jelzi, hogy szeretné beletenni a munkáját a közösbe. Ezen a ponton annak, aki ezt elbírálja és elfogadja, nagyon észnél kell lennie, mert létrejöhetnek különböző conflict-ok, amik abból adódnak, hogy időközben megváltozott a központi kód és ha gondolkodás nélkül rátoljuk a friss fejlesztést, ami még egy korábbi verzión alapszik, az pillanatok alatt hazavághat több hétnyi munkát.

Logikáját tekintve a következő módon épül fel:

1. Létrehozunk egy központi repository-t. Ez lesz az adatbázis, ami lényegében egy mappa a verziókezelt fájlokkal.
2. Létrehozzuk a „main”-t, ami tulajdonképpen olyan, mint egy fa főága. Ez lesz az az ág, ahova mindent összeolvasztunk (merge-ölünk).
3. A main-ből különböző elágazásokat (branch-eket) készítünk és ebben végezzük a tényleges munkát, majd amikor kész van, visszatesszük a main-be.
4. Amikor legközelebb dolgozni akarunk, fontos, hogy mielőtt nekikezdünk, kérjük le, milyen frissítések történtek azóta, hogy elkerüljük a felesleges conflict-okat.

Azt természetesen figyelembe kell venni, hogy a teljes rendszer korántsem ennyire egyszerű. A Git ennél sokkal több és sokkal összetettebb módon működik, többféle lehetőséggel, de ahhoz, hogy megértsd a további működését, az alaplogikát kell elsajátítanod. Ha ennél mélyebben ásnád bele magad magad a Git rendszerek gyakorlati működésébe, ajánljuk a C# Tutorial útmutatóját, vagy méginkább egyenesen a Github git guide-ját, ahol egyébként ingyenes a regisztráció és akár saját projekteken is gyakorolhatod a Git működését, amihez még csak kódolni sem kell.

***

Ha érdekelnek az IT világához kapcsolódó témák, szemezgess korábbi cikkeink között, illetve javasoljuk, hogy vess egy pillantást informatikai képzéseinkre.
Webfejlesztő
Webszerkesztés alapjai
Junior frontend fejlesztő
Junior Java backend fejlesztő
Junior szoftvertesztelő
Junior rendszerüzemeltető