A Git egy elosztott verziókezelő szoftver. Ez így tiszta kínai, szóval mielőtt ész nélkül belevágunk, beszéljünk egy kicsit magáról a koncepcióról. Azaz: mi is az a verziókövetés? És miért van rá szükség? Jöjjön egy elméleti bevezető!
Verziók a hétköznapokban
 |
| Dizájn verziók, szerző: Liam Jay |
Mindenki dolgozott már verziókezeléssel, legfeljebb nem hívta így. Volt valaha, hogy mentés másként gombra kattintva készítettél egy másolatot egy fájlról? Verziókezelés. Egy komolyabb képszerkesztés során a köztes lépéseket külön fájlba írtad? Verziókezelés. Projektenként külön mappát hoztál létre és oda mentettél mindent? Verziókezelés. Írtál Wordben bármit? Verziókezelés! Regényírásnál valaki javított neked? Kitaláltad: verziókezelés!
A verziókezelés mindenhol ott van. Nem kell ehhez számítógép sem, egy sima fénymásolt papír is elegendő, de azért a fájlok között éljük ki magunkat igazán a verziókkal.
Maga a koncepció nem teljesen idegen, ez megnyugtató. Igazából nem is jelent mást, mint amit az intuíció diktál: különféle adatok és azok verzióinak kezeléséről beszélünk. Bármilyen projekt során lehet jelentősége, elsősorban akkor kiemelkedő, ha több ember is dolgozik (akár egyszerre) ugyanazon a munkán. Mivel az egyes változatok könnyen megkülönböztethetőek, a szerzők személye és a módosítások is egyértelműek, mindenki láthatja, ki, mikor és mit változtatott.
Verziókezelés a programozásban és az írásban
Programozás során elsősorban szövegfájlokkal dolgozik az ember. Az ilyen fájlok kezelése egyszerűbb a képekhez képest, hiszen pontosan kiemelhető, hol és mi változott. A profi verziókezelő rendszerek és szoftverek pedig ezt teszik számunkra lehetővé. Igazából kézzel is kigyűjthetnénk egy fájlba, hogy most itt a harmadik sorban átírtam egy elgépelt szót, aztán a negyvenkettedikben beszúrtam még egy mondatot – de ha már vannak ilyen szoftverek, amik ezt teszik lehetővé, miért ne használjuk azokat?
Várjunk egy percre! Ha szövegfájlokkal dolgozunk, ez azt jelenti, hogy akár a sima blogcikkeket, vagy akár egy regényt is meg lehet így írni? Persze, természetesen. Én ezt a cikket is így írom, novellákat is így szoktam. Egy regénynél pedig igazán szárnyalhat a verziókezelést használó szerző. Nincs többé “jaj, írjak-e alternatív befejezést ehhez a fejezethez?”. Írj, aztán legfeljebb leváltod! Nincs többé, hogy a csúcsponton derül ki, hogy véletlenül kitöröltük a főszereplő eredeti motivációját jelentő fejezetet. Egyszerűen visszakeressük, megnézzük, mi változott, és vagy visszaállítjuk, vagy beépítjük máshová. Sőt, így a társírókkal való együttműködés is sokkal egyszerűbb, hiszen mindenki látja és tudja, a másik mit alkotott, mibe nyúlt bele és miért. Csodás világ! (Legalább hivatalos bizonyítékunk van rá, hogy Lujza tényleg kitörölte azt a részt, ami annyira jó volt, és nyugodtabban fojthatjuk meg egy kanál vízben.)
Verziókezelő rendszerek előnye
Kell nekünk professzionális verziókövető program? Nem, igazából lehet élni nélküle (de minek). Azonban egy egy projekten többen is dolgoznak, akkor nem tudjuk megúszni a használatukat, vagy kénytelenek leszünk valamiféle házi szabályzatot alkotni, amivel ezeket másoljuk. Az egyik kérdés annak eldöntése, hogy ha egy fájlt szeretnének többen is módosítani, akkor mi történjen. Ezek az úgynevezett kezelési modellek. A másik kérdés, hogy hol tároljuk a fájlokat: a centralizált modellben egy szerveren vannak, míg az elosztott modellben mindenkinek van egy.
Kezelési modellek: lock és merge
❗ Sajnálom, de innentől kezdve jönnek az angol kifejezések. Igyekszem mindent lefordítani magyarra az angolul nem beszélők kedvéért, de a számítástechnika nyelve az angol. Éppen emiatt rengeteg a nehezen fordítható kifejezés, vagy az olyanok, amiket mindenki angol változatában használ.
Kétféle kezelési modellt különböztetnek meg a verziókövető rendszerek. Az első a lock, azaz zárolási modell. Ilyenkor ha egy fájlt valaki szerkeszt, akkor ahhoz senki más nem fér hozzá csak olvashatja. Azaz egy időben egy felhasználó szerkeszthet egy fájlt. Ezt azzal érik el, hogy a szerkesztés idejére az adott személy kiveszi (check-out) a fájlt, így annak csak egy olvasható lenyomata marad a rendszerben. Utána a felhasználó dönthet, beadja (check-in) a fájlt vagy elveti a módosításokat és minden marad az eredetiben. Check-in után a fájl újra szabadon szerkeszthető mások számára is.
A másik kezelési modell a merge, vagyis összefésülés. Ilyenkor annyi ember dolgozik egyszerre, ahány szeretne. De mi van, ha mindenki befejezte, kinek a változásai érvényesülnek a központban? Sima verseny: aki először adja be. A többiek lemaradtak, nekik a rendszer felkínál egy összefésülési lehetőséget ezzel a módosított verzióval. Ezt vagy elfogadják és akkor a kétféle szerkesztés beépülhet a fájlba, vagy elvetnek minden saját módosítást és csendben sírnak a sarokban.
Centralizált és elosztott verziókezelő modellek
A centralizált rendszerben van egy központi szerver, és minden fájl oda kerül mentésre. Ez az Igazság, mármint nem az Egyetemes Igazság, hanem a projekt éppen érvényes változata. Minden más a felhasználók gépen csak játszótér, nem létezik a kód szempontjából.
Nem csak egy igazság van a világon. Vannak olyan verziókezelők, amik ezt vallják. Ez azt jelenti a gyakorlatban, hogy egy központi respsitory, tároló helyett minden gép egy-egy saját tároló egység. Csak munkamásolatok vannak, nincs egy Központi Igazság, amit követni kell. Emiatt gyorsabb, mint a centrális, hiszen nem kell egy esetleg túlterhelt szerverrel beszélgetni, hanem mindenki a saját gépen a saját fájljai között dolgozik és később ezeket fésülik össze. Plusz előny, hogy ami az én gépem van, az ugyanúgy ott van a tiéden is, ami egyfajta biztonsági mentés, ha az én gépemet formattálná egy kósza lokális napkitörés.
Nagy előny továbbá, hogy nem vagyunk egymáshoz láncolva. Sőt, bárki bármikor bekapcsolódhat, nem kell előzetesen engedélyt kérnie a szerzőtől. A mindenki által elérhető központból, én azt töltök le, ami nekem kell, és te azt, ami neked. Hé, te jobban preferálod a regény alternatív befejezését? Oké, akkor a te gépeden az lesz. Ha nekem a kanonikus jön be, akkor nálam meg az. A két repository (röviden repo, ezt még sokat fogom használni) létezhet egymás mellett békében.
Egészen addig, amíg valami okból össze nem kell ezeket fésülni. Merge, igen. Kinek a változata érvényesül? Ez egy komoly kérdés, és ha nem tudunk megegyezni, az a merge conflict (összefésülési konfliktus?). Általában jön a főnök/író és eldönti. 🙂
Mi mit fogunk használni?
A Git egy elosztott verziókezelő rendszer. Na, ezt most mér értjük is. Ezt fogjuk használni a továbbiakban. A következő fejezetben az elmélet után jön egy kicsit gyakorlatiasabb szemlélet és beszélek a Git sajátosságairól és megnézzük a későbbiekben használt szoftvert is, a GitHub Desktopot.
Megjegyzések
Megjegyzés küldése