Miért érdemes a Git verziókezelőt megtanulni?
Hallottad vagy átélted már a következő helyzeteket?
Nem vagyok biztos benne, hogy ez jó lesz. De elég sok átalakítást igényel, úgyhogy várj egy kicsit, előbb készítek egy biztonsági mentést a mostani projektről, hogy ha valamit elrontok, akkor oda vissza tudjunk térni – vagy csak ki tudjunk belőle venni részeket, amik még majd kellenek.
Ne haragudj, de most nem tudjuk folytatni a múltkori feladatot, mert előző alkalommal a másik gépem volt nálam, és elfelejtettem átmásolni a projektet. Mivel foglalkozzunk ma?
Tudod, az történt, hogy amikor újratelepítettem a rendszert, ezt a mappát elfelejtettem lementeni, és sajnos ez is áldozatul esett.
Bocsánat, tönkrement a gépemben a háttértár, ez a nővérem gépe, kölcsönadta, hogy tudjunk tanulni, épp az óra előtt sikerült befejeznem a fejlesztőkörnyezet telepítését. De amúgy ott tartottunk, hogy…
Átküldenéd kérlek a projekt jelenlegi állását? Szeretném megnézni a következő órára. A GMail letiltja a futtatható állományokat, úgyhogy valami nagylevélküldővel küldd…
Ha hallottál vagy átéltél már hasonló beszélgetéseket, akkor tudhatod, hogy mennyire nagy problémát jelentenek a fenti mondatok.
Megsemmisülő munkák
Talán ez mind közül a legrosszabb. Az ember dolgozik valamivel napokat, akár heteket, majd – egy bármely pillanatban előforduló hardveres meghibásodás vagy akár csak egy kis figyelmetlenség miatt – minden semmivé foszlik. Oda a projekt, a belefektetett idő, munka, az eredmény maga. Sovány vigasz, hogy másodszorra már gyorsabb megírni.
Másik gépről nehezen elérhető projektek
Ha valakinek van asztali gépe és laptopja is – vagy családon belül van több eszköz -, akkor biztosan szembesült az adatmozgatás nehézségeivel. Legrosszabb esetben az ember fog egy pendrive-ot, rámásolja az egyik gépen azt, amit át akar mozgatni, és a másik gépen meg lemásolja róla. Kicsit nehézkes, de egyszerű, és kézenfekvő megoldás. Esetleg elküldi magának emailben, és a másik gépen a postafiókból kimásolja. Csak a GMail nem enged futtatható fájlokat küldeni.
Különböző változatok kezelése
Egy nagyobb módosítás előtt érdemes elmenteni a korábbi verziót, hogy vissza tudjunk térni hozzá, ha valami balul sülne el. Ilyenkor mi lehet a megoldás? Ha van egy könyvtárunk, amiben a fejlesztett projektünk van (myproject), akkor készítünk egy másolatot róla „myproject-2” néven. És kész. A következő lépés „myproject-3”, majd a „myproject-2”-t szeretnénk mégis továbbfejleszteni, szóval akkor lesz egy „myproject-2-20201003”, amit folytatunk. Ebből aztán megint készül egy mentés, „myproject-20201005-jo”, és ha végül befejezzük, akkor lesz egy „myproject-final”. Majd az első hibajavítás után „myproject-final-2”, a második után „myproject-final-20201102”, és így tovább. Kb. a harmadik lépésnél valószínűleg már azt sem tudjuk, hogy melyik projektünk micsoda, miből másoltuk, és mit változtattunk rajta, tehát a visszatérés az előző verzióhoz azért is nehéz, mert fogalmunk sincs, hogy melyikre is kellene visszatérni.
Verziókezelés
A fenti problémákra van megoldás, verziókezelésnek (angolul version controlnak hívják), és nagyon régóta jelen van az informatikában.
A verziókezelés kifejezést leggyakrabban valamilyen szoftverforráskóddal hozzák kapcsolatba, de lehetséges bármilyen alkotótevékenység eredményét is verziókezelni.
Szükség van arra, hogy az adatainkat bármilyen okból kifolyó adatvesztés (pl. elveszítem a gépem, tönkremegy a háttértár, véletlenül letörlök valamit) esetén biztonságban tudhassuk. Ezért mindenképpen kívül kell kerülniük az adatoknak a számítógépünkön, és lehetőleg messzebbre (irodatűz, 9/11).
Központosított verziókezelés
Az első néhány eszköz (pl. CVS – Concurrent Versions System (1990), SVN – Subversion (2000)) azt a megoldást alkalmazta, hogy adott volt egy speciális központi gép, amely fogadta az elmenteni kívánt változatokat, viszonylag biztonságosan eltárolta. Mivel ez általában vállalati környezetben történt, a rendszergazda szakképzett ember, ezért időről időre mentéseket készített, és felkészítette a rendszert a lehető legtöbbféle katasztrófa kezelésére. (Pl. naponta/hetente mentéseket készített, a szalagokat az iroda tűzálló széfjébe helyezte).
Ez volt az ún. központosított rendszer.
A szerver tartalmazta az összes változatot, a munkatársak gépén csak az aktuális volt elérhető.
De ez nem 100%.
Mentési periódusokon belül is történhetnek problémák (heti mentés esetén hét közben), illetve lehet, hogy maga a mentés is megsérül (9/11, összeomlik az épület).
Elosztott verziókezelés
Modernebb megoldás, ha az összes verziót tároljuk az összes rendszerben lévő gépen, nemcsak a központi szerver minden titkok tudója (amely ha megsérül…). Így már gyakorlatilag nincs is különbség a munkatársak gépei és a „központi szerver” között, az egyes résztvevők gyakorlatilag egyenrangúvá válnak. Persze továbbra is lehetséges egy bizonyos gépet kijelölni „központi gépnek”, de ez inkább választás, mint kényszer kérdése.
A Git verziókezelő is elosztott verziókezelést kínál.
A Git elosztottsága miatt nem rémültem halálra, amikor az általunk használt központi gépként viselkedő (cloud) szolgáltató oldalán egyik reggel megjelent, hogy „Bocs srácok, az elmúlt másfél nap mentései elvesztek, még fél nap, és helyreállítjuk az azelőtti állapotot.”
Ez ugyanis a Git esetében nem jelent adatvesztést. Minden munkatárs gépén ott a projekt összes változata. Ha elvész a központi gép, akkor is megmarad minden. Legalábbis amíg van egyetlen működő számítógép, amin ott van a gites projekt.
Miért a Git?
- Az elmúlt években de facto szabvánnyá vált a verziókezelésben, kevés és egyre kevesebb céget lehet találni, amelyik más megoldást használna
- Elosztottsága miatt amíg egyetlen ép gép van az adott projektben, a munka 100%-ig visszaállítható
- Internet nélkül is tudunk vele dolgozni (egy repülőn pl.), tudunk menteni a saját változatunkba, amit majd leszállás után szinkronizálunk a többiek változatával
- Nagyon sokféle verziókezelési struktúrát támogat
- Könnyű benne „próbaágakat” létrehozni
Miért érdemes tanulni róla?
Azt látom sok tanítványomon, hogy a Git bennemarad a „meg kéne tanulni azt is” kategóriába, de nem szánják rá magukat, hogy tényleg megtegyék. Pedig a fenti problémák rájuk is leselkednek, a verziókezelés által kínált előnyöket meg nem használják ki.
A cégek meg attól használják, és felvételin számonkérik.
Céges szinten pedig azért érdemes a (kezdőbb) munkatársakat elküldeni egy tanfolyamra, mert – tisztelet a kivételnek – nem csak „betanított munkásként” fogja használni a Gitet (verziót így mentesz, feltölteni így töltesz fel…), hanem érteni is fogja az összefüggéseket, nem fog esetleg valamit nagyon összekutyulni.
Ha szeretnéd te is megtanulni, látogass el a Git tanfolyamunk oldalára.
Pasztuhov Dániel
StudiCore Kft.
Ha bővebben érdekel a Git, nézd meg ezt:
