Írta: tom1964h

Verziókezelési modellek#

A verziókezelők alapszolgáltatása a tároláson túl: két eltérő verzióban létező állomány (két példány) tartalmi összehasonlítása, annak követése, hogy egy file-t ketten (eltérő módon) módosították; a verziókezelő észleli a párhuzamos módosításokat. Összefoglalva néhány fő, megkívánt hasznosság és előny:

• minden fejlesztő egyidőben ugyanazon a kódbázison dolgozhasson, támogassa a gyors szinkronizálást
• a változások követhetőek legyenek, megjegyzések és magyarázatok legyenek hozzáfűzhetők az egyes változatokhoz
• elérhető legyen a folyamatos mentés és visszaállíthatóság (kvázi időgép lehetőség)
• fontos, hogy tudjak egy teljes másolaton további funkciókat fejleszteni, hibákat keresni és javítani, anélkül, hogy a már működő eredetit veszélyeztetném - ha sikeresnek bizonyul a fejlesztés, akkor beolvaszthatom a fejlesztői másolatot (branch-et) az eredeti ágba
• minden változáshoz rögzítse a rendszer a szerző adatait: legyen egyértelmű a felelősség, a hibák visszakereshetők legyenek.

A verziókezelő rendszerek fejlesztése során két fő iskola / megoldás-típus alakult ki:

A központosított illetve az elosztott verziókezelés önmagában módszertanoknak tekintendők. Az SVN vagy a GIT ezen módszertanok megvalósításai (ahogy pl. a programozási nyelv is egy gyűjtőfogalom, a JAVA ennek a fogalomnak az implementációja).

Egyik módszertan sem jobb, az igények határozzák meg a használt technológiát.

Commit#

Verziókezelésnél mindig létezik egy repó, amelybe a fejlesztés során bekerülnek a friss állományok, a verziókezelő pedig verziót kezel, azaz követi a változásokat: tracking. Az egyik alapműködés a commit paranccsal hajtható végre, amellyel a megjelölt file-okat elküldjük|rögzitjük|érvényesítjük a repóban (szabatosabb meghatározást lásd git-commit git-scm.com). A commit fontos szerepet játszik még pl. a relációs adatbáziskezelők világában, funkciója nagyjából ugyanaz (lásd commit).

SVN#

Egy szervernek küldjük az adatot. Ehhez minden esetben internetes kapcsolat szükséges - összeköttetésben kell lennünk a szerverrel. A commit hatására a beküldendő állomány(ok) azonnal bekerülnek a repóba. Minden fejlesztő ezzel az egy repóval dolgozik. Probléma akkor adódik, ha két fejlesztő is ugyanazon az állományon módosított. Ekkor konfliktuskezelést kell végezni, amiben a rendszer segítséget ad.

_{központosított repó}

Egy egyszerű munkafolyamat (workflow) így nézhet ki:

• egy szerveren létesített központi könyvtárnak küldjük a friss módosítást egy commit kiadásával
• a szerver regisztrálja ezt (frissíti a verziót és a verziószámot)
• a másik fejlesztő rendszeresen lekérheti ezután a legfrissebb változatot saját gépére: ez az update request (a Git esetében ez a pull)
• ezzel elkészül egy local copy, helyi másolat.
• ha a másik fejlesztő változtat a forrásállományon és egy commit után felküli a szerverre a friss állományokat
• szerver regisztrálja ezt (frissíti a verziót és verziószámot) … … stb stb stb
  
  

  
  _{központosított repó működése}

Git#

A Git alapeleme ugyancsak a repó, amely lehet helyi (local repo) vagy távoli (remote repo). Röviden a Gitről:

• lehetséges csak helyi repóval is dolgozni, internet nélkül, ami nagyobb szabadságot ad
• minden kliens gépen van egy vagy több helyi repó
• a teljes repót tároljuk, a központi repó másolata (a pull pillanatában)
• mivel forráskódokat tárolunk, kis helyet foglal el

Használata:

• cégeknél elvárt a rendszeres pull request (lásd később), azaz folyamatosan frissíteni kell a helyi repót
• munka végeztével legalább, de gyakrabban is ajánlott push requestet (lásd később) küldeni - azaz frissíteni kell a központi repót
• és viszont, nekünk is frissíteni kell (egyes desktop alkalmazások eleve felajánlják a push-t)
• konfliktuskezelés itt is szükséges, az SVN-hez hasonló módon

_{osztott verziókezelés demó}

_{forrás draw.io}