ITHub

Amit tudnod kell fejlesztőként, IV. rész: Verziókezelés

Amit tudnod kell fejlesztőként, IV. rész: Verziókezelés
Farkas Gábor
Farkas Gábor
| ~4 perc olvasás

Ma már bármilyen szoftverfejlesztési projekt alapvető eleme valamilyen verziókezelő rendszer, amely nélkül a forráskódot érintő változások megfelelő követése elképzelhetetlen lenne. Sorozatunk következő részében ezeket tekintjük át az eddigiekhez hasonló, kissé felületes módon, a cikk mégis hasznos lehet a témával még csak ismerkedőknek, mert néhány jó forrást is igyekszem belinkelni, amin tovább lehet haladni. Ha egyből ezekre vagy kíváncsi, kattints ide.

Amit fejlesztőként tudnod kell, IV. rész: Verziókezelés

Először is érdemes tisztázni, miért is van szükség egyáltalán verziókövetésre? Íme néhány pont, amelyek a fő előnyöket foglalják össze:

  • Backup és visszaállítás. A fájlok a szerkesztés közben mentésre kerülnek, és bármikor visszaállíthatók. Szükséged van a 2007. február 4-i verzióra? Nem gond.
  • Szinkronizáció. Ha egy szoftveren egynél több ember dolgozik, fontos, hogy folyamatosan a kódbázis legfrisebb verzióját lássák mindannyian.
  • Változások követése. Ahogy a fájlok változnak, az egyes változtatások üzenetekkel láthatók el, amik leírást adnak arról, hogy mit és miért csináltunk.
  • Felelősség követése. Mivel az egyes változtatások egyértelmű felhasználóhoz/fejlesztőhöz köthetőek, mindig pontosan tudhatjuk, ki és mikor követett el bizonyos változtatásokat, nincs több egymásra mutogatás.
  • Elágazás (branching) és összefésülés (merging). A kódbázis egy másolatát lemásolhatod egy külön ágba, hogy ott aztán elkülönítve követett változtatásokat hajts végre. Amint elkészült, ezeket a változtatásokat akár össze is fésülheted az eredeti kódbázissal.

Érdemes megismerkedni néhány alapfogalommal. Az adatbázist, amely a fájlokat és azok összes verzióját tárolja, a legtöbb esetben repository névvel illetjük, a kódbázis helyi verziója, amin éppen dolgozunk, pedig a working copy. A revision a verzió szinonimája: fájlok halmazának egy egyértelműen azonosítható változata, a head pedig a repositoryban található legfrisebb verzió. Egy branch létrehozásakor másolatot készítünk az egész kódbázisról, amit aztán külön láthatunk el változtatásokkal. Ez nagyon hasznos például akkor, ha egy új funkción dolgozunk a kódban, de ez akár hosszú ideig is tarthat, és csak kész állapotában szeretnénk majd belefoglalni az éles szoftverbe. Amikor a funkció elkészült, egy merge művelettel tehetjük ezt meg. Ilyenkor ütközés, conflict jöhet létre, hiszen a miénktől függetlenül fejlődő másik ágban akár ugyanazok a fájlok is módosulhattak, amelyeken mi dolgoztunk. Ezeket az ütközéseket fel kell oldani (resolve) a verziók megfelelő összefésülésével.

Az egyik legkorábbi verziókezelő rendszer a CVS (Concurrent Versions System). Az alapvető igényeket kielégíti, hiszen a fejlesztők lemásolhatják a repositoryt, és a helyi változtatásaikat vissza is írhatják abba. A CVS az ütközéseket eredetileg egy meglehetősen egyszerű, first come, first serve modellel oldotta fel, ami azt jelenti, hogy változtatást mindig csak a szoftver legfrissebb verzióján lehet végrehajtani. Emiatt gyorsan és gyakran kellett a változtatásainkat visszatölteni a repositoryba, nehogy valaki megelőzzön minket. A CVS ma már támogatja a branchinget, így valamivel rugalmasabb. Fő előnye, hogy régóta jelen van, így stabilnak mondható, azonban néhány alapvető hibája miatt (nincsenek atomi műveletek - ld. később, a branching nagyon költséges művelet) ma már kevésbé népszerű.

Az Apache Subversion (SVN) annak idején a CVS alternatívájaként jött létre, ami számos bug kijavítása mellett megpróbált maximális kompatibilitást biztosítani az eredeti rendszerrel. Az adatbázis konzisztenciáját az SVN atomi műveletekkel biztosítja: egy adott változtatásnak vagy minden összetevője bekerül a repositoryba, vagy egy sem. Míg a CVS-ben a branching lassú művelet, és nem is igazán támogatta a rendszer a hosszú életű brancheket, az SVN-t sokkal inkább erre találták ki. Fő negatívumaként azt szokták felhozni, hogy centralizált: a repository egyetlen központi helyen van tárolva. Ennek az a fő hátránya, hogy ha ez a központi szerver valamiért épp nem elérhető, a fejlesztők nem tudnak hozzáférni a kódbázishoz.

Ennek a problémának az orvosolására hozta létre Linus Torvalds a Git nevű verziókezelő rendszert, amely ma egyértelműen az egyik legnépszerűbbnek számít. A Git egy radikálisan új modellel állt elő a CVS-hez és az SVN-hez képest: a rendszer teljesen elosztott, így nincs szükség egyetlen központi repositoryra. A Git általában véve elődeinél sokkal gyorsabb, és a teljes verziótörténet offline is elérhető minden egyes kliensen.

Említésre méltó versenyző még a Mercurial, amely szintén elosztott, de több hasonlóságot mutat az SVN-el, így talán némileg gyorsabban tanulható azok számára, akik SVN-ről térnek át egy elosztott rendszerre.

Ha választani kellene, valószínűleg az SVN-et és a Git-et mindenképp érdemes megtanulni — mindkettőhöz rengeteg jó anyag található a neten, az alábbi listában össze is szedtem párat, illetve az elején néhány általános, a verziókövetést részletesebben áttekintő cikk is található: