Foglalkoztatott már korábban a kérdés, hogyan dolgozik egy nagy számítástechnikai projekten egyszerre többszáz vagy akár több ezer ember is? Hogy osztják meg egymás közt a fájljaikat? Hogyan oldják meg, hogy semmilyen file ne vesszen el és mindenki mindig a projekt legújabb verzióján dolgozhasson?
Erre a válasz először is sok fegyelem és tapasztalat. Másrészről a célra az iparágban szinte minden cégnél használatba szoktak venni egy szoftvert, amit verziókezelőnek vagy VCS-nek nevezünk. Ezen rendszerek közül a legelterjedtebb manapság a git nevet viseli.
VCS
/w=48,quality=90,fit=scale-down){kind=small}
Egy verziókezelő szoftver elsődleges feladata, hogy nyomon kövesse egy projekt mappa tartalmának változásait egy számítógépen és ezen változásokat megfelelő parancsok hatására szinkronizálja egy szerveren tárolt verzióval.
Segítségével nagy csapat tud egyszerre dolgozni egy projekten több számítógépről.
Egy VCS egyszerre tárolja nem csak a legújabb de minden korábbi “mentett” állapotát egy projektnek. Mindezt úgy teszi, hogy mindig csak az változtatott fájlokat tárolja el a rendszer, ezáltal egy projekt mérete nem duzzad hamar túlzottan nagyra.
Ezáltal egy VCS lehetővé teszi a fejlesztőknek, hogy a projekt bármely verziójára visszaálljanak valamint, hogy könnyen nyomon kövessék és összehasonlítsák a kód változásait.
A legnépszerűbb VCS-ek a Unity játékfejlesztéshez:
- Git
- Plastic
- SVN
Egy VCS használata akkor is javasolt, ha egyedül dolgozol egy projekten.
- Egyfelől azért, mert így akár több számítógépről is hozzá tudsz férni egy projekthez és a szinkronizálás ezen számítógépek közt kényelmes és gyors lesz.
- Másfelől minden kreatív vagy mérnöki területen alkotó személynek ajánlott, hogy megtartsa egy forrásfájl kód, kép, modell vagy bármi egyéb minden korábbi verzióját és lehetőleg nem csak lokálisan, hanem egy szerveren is egyaránt. Ebben is segít egy VCS.
Segítségével a teljes projekt vagy bizonyos kiválasztott fájlok korábbi állapota visszaállítható, különböző verzióik kényelmesen összehasonlíthatók. A VCS használata általában azt is jelenti, hogy ha ez ember elront valamit, vagy elveszíti a fájlokat, könnyen helyreállíthatja a hibát.
A git
A git egy ingyenes és nyílt forráskódú elosztott verziókezelő rendszer, amely segítségével egy projekten könnyedén dolgozhat számtalan számítógépről bárhány fejlesztő egyszerre.
A Git első változatát Linus Torvalds készítette el a Linux kernel fejlesztéséhez. Ezen verzió változata 2005-ben jelent meg. Mára a git a legnépszerűbb VCS és világszerte sok millióan használják szoftverfejlesztésre és egyéb kreatív feladatokra egyaránt.
A git egy úgy nevezett elosztott (Distributed) verziókezelő: DVCS. Ez azt jelenti, hogy bár létezik egy fő szerveres verzió, minden egyes számítógép, amiről valaki dolgozik a projekten, az egy teljes másolatot tartalmaz az egész projektről. Ezáltal a projekt a lehető legnagyobb biztonságban van, több számítógépen is eltárolva. A D VCS ebben az esetben, arról gondoskodik hogy valamennyi lokális példányát a projektnek könnyedén és biztonságosan tudjuk szinkronizál egymással.
Alapfogalmak
Most definiáljuk a VCS-ekhez és kifejezetten a git-hez kötődő legfontosabb fogalmakat.
- Repository
- Újonnan létrehozzuk egy meglévő mappából, aztán ezt a repository-t publikálhatjuk egy git szerverre.
- Klónozhatunk meglévő repository-t egy git szerverről.
- Klónozás
- Stage
- Commit
- Push
- Fetch
- Pull
Egy repository vagy röviden repo egy projektet reprezentál annak minden korábbi állapotával együtt. Git repo-t többféleképp hozhatunk létere:
Klónozás az a művelet, amikor egy szerveren már létező git. repository-ból egy lokális másolatot készítünk.
Ha egy lokális repository-ban bármi változás történik egy fájlon: Létrejön, törlődik, módosul, akkor azt a git automatikusa és nagyon gyorsan “észreveszi”. Ekkor lehetőségünk van ezt a fájlt stage-elni. Ha egy fájl stage állapotban van, ez azt jelenti, hogy készenáll arra, hogy “elmentsük” a változást.
A Commit egy adott állapotát reprezentálja a projektünknek. Érdemes a commit-ra úgy tekinteni, mint egy “checkpoint” vagy egy mentés egy játékban. Ha egyszer készítettünk egy commit-ot, arra később bármikor visszaállhatunk. A commit parancs kiadásakor a stage állapotban lévő fájlok változásai kerülnek mentésre.
A commit, azaz egy adagnyi változás mentése a repository-nak csak a lokális verzióján történik meg. Ez a művelet nem fog semmilyen változást eredményezni a szerveren.
A push művelet kiadásával lehet egy aktuális lokális commit-okat. Feltölteni a szerverre.
A fetch művelettel lekérhető, hogy a szerveren tárolt verzióján a repository-nak van-e bármi olyan új commit-ja, ami nincs még meg a mi lokális repo-nkban.
A pull művelettel lehet a szerveren tárolt repository új commit-jait letölteni a lokális repo-nkba.
Két fajta repository-t tudunk létrehozni, egyik a publikus és másik a privát. A publikus repository-k bárki számára hozzá férhetők, ám ez nem azt jelenti, hogy bárki módosítani is tud rajtuk. Ehhez extra jogosultság kell.
A privát repository-k csak a felhasználók egy csoportja számára elérhető: Ezek a projekt tulajdonosa, létrehozója és minden olyan felhasználó akinek a projektgazda jogot ad ehhez.
Javaslom, gyakorláshoz nyugodtan használjatok publikus repository-kat.
A GitHub
A GitHub egy weboldal, ami egyben a legnépszerűbb online Git szerver szolgáltató is. Használatával nem szükséges nekünk egy git szervert telepíteni és fenntartani.
Ingyenesen használható minden felhasználó számára…
- publikus repository-kra korlátlanul.
- privát repository-k esetén 15 gigabyte tárhelyig.
Ha kifogynánk a privát repository helyből, akkor lehet később magasabb fizetős csomagra előfizetni vagy a projektet más git szerverre migrálni, de ettől egyelőre nem kell félni.
A továbbiakat ezen szerver használatával mutatom be. Javaslom mindenkinek, hogy használja bátran a GitHub-ot most a tanulás alatt és utána is. Ehhez legelőször mindenki regisztráljon egy fiókot magának az oldalon!
Git szoftver telepítése
A git alapvetően egy parancssori szoftver, de mi ezen leckében nem fogjuk megismerni a parancssoron keresztüli használatát. Helyette egy kényelmes asztali felhasználói felületen keresztül fogjuk elérni a legfőbb funkcióit. Ettől függetlenül a parancssori verziót mindenképp érdemes telepíteni és hosszútávon legalább a legfontosabb parancsok megtanulása is javasolt.
A parancssori git innen tölthető le:
A git-hez számtalan asztali kliens alkalmazás használható különböző szintű funkcionalitással. Ezek közül mi most a GitHub saját szoftverét, a GitHub Desktop-ot fogjuk használni.
A GitHub Desktop innen tölthető le:
Telepítsük a fenti szoftvereket, majd jelentkezzünk be a GitHub Desktop alkalmazásba!
Hozzunk létre egy repo-t!
Két lehetőségünk van repository-t létrehozni.
- Egyik módszer az, hogy a GitHub webes felületén a szerveren hozunk létre egy üres repo-t, majd utána klónozzok azt, lokális másolatot hozva létre belőle.
- Új repot a GitHub weboldalán bejelentkezve a nagy zöld New feliratú gomb megnyomásával tudunk létrehozni.
- Adjunk neki egy nevet és ne változtassunk semmi egyebet a beállításokon.
- Ezután kattintsunk a Create Repository feliratú gombra!
- Klónozzuk a szerveren lévő repository-t a számítógépünkre! Ehhez lejjebb találsz leírást.
- Adjátok hozzá a .gitignore fájlt a projekt mappa gyökerébe majd commit-oljátok a változást! Ehhez lejjebb találsz leírást.
- Másik lehetőségünk, hogy egy meglévő mappából készítünk lokális repository-t majd ezt publikáljuk a szerverre. Ha van már egy létező projektetek, amiből szeretnétek egy repository-t, akkor javaslom, ebbe az irányba induljatok..
- Ha ezt a stratégiát választjátok, akkor mindenek előtt feltétlenül olvassátok el a .gitignore fájlról szóló fejezetet és adjátok hozzá a letölthető .gitignore fájlt a projekt gyökeréhez.
- Utána GitHub Desktop-on keresztül lehet új repot létrehozni: File / New Repository.
- Adjuk meg a megfelelő elérési utat és a mappa helyét majd kattintsunk a Create Repository feliratú gombra!
- Ellenőrizzük, hogy a Repo gyökere valóban a kívánt projekt mappa lett-e és nem pedig a projektünkön belül hozott létre egy új mappát a GitHub Desktop! Ha utóbbi eset történt meg, akkor töröljük ezt az új mappát majd kezdjük elölről.
- Végül kattintsunk a Publish gombra, hogy a repo-t feltöltsük a szerverünkre.
Vegyük észre, hogy ekkor egy új rejtett mappa jött létre a projekt mappánk gyökerében .git néven. Ez fogja tárolni a repository fájljainak minden múltbéli verzióját.
A .gitignore file
Sok esetben nem szeretnénk, hogy egy projekt mappa minden fájlja a repository része legyen. Különösen szoftveres keretrendszerekre igaz, hogy rengeteg apró gyorsítófájlt hoznak létre és használnak a projektmappán belül, amik az ő működésükhöz szükséges, de nekünk mint fejlesztőknek nem kell velük foglalkozni. Mind a Unity, mind a Visual Studio létrehoz sok sok ilyen fájlt. Ezeket, nem szeretnénk nyomon követni, sem szinkronizálni. Azt akarjuk, hogy a git egyáltalán ne foglalkozzon velük, azaz ignorálja őket.
Erre való a .gitignore fájl, ami egy speciális kódot tartalmaz, amit a projektbe helyezve szabályokat adhatunk arról, hogy milyen mappákkal és file-okkal ne törődjön a git.
Az alábbi .gitignore file kifejezetten Unity és C# projektekhez javasolt.
Töltsétek le és tegyétek a projekt mappa gyökerébe!
Figyelj arra, hogy a file neve pontosan ez legyen “.gitignore” (beleértve a kezdő pontot is)!
A Klónozás, Fetch és Pull
Ha szerveren van egy repositorink és abból egy lokális változatot szeretnénk létrehozni, akkor van szükségünk a klónozásra. Github desktopon keresztül 2 módon tudunk klónozni. Mindkét esetben indítsuk a folyamatot a Főmenü / File / Clone gomb megnyomásával.
Ha olyan projektet akarunk klónozni, amihez extra jogosultságunk van, (mert például mi hoztuk létre) akkor a GitHub.com fül alatt fel lesznek sorolva az elérhető repo-k. Persze ehhez bejelentkezve kell lennünk az asztali alkalmazásban.
Ha egy olyan repo-t akarsz klónozni, ami nem a tiéd, nincs hozzá írási jogosultságod, akkor ezt egy Git URL segítségével teheted meg.
Ez egy karaktersor, amit az adott repository GitHub oldalán tudsz lekérni a kód gombra kattintva. Ezt a szöveget kell a GitHub Desktop-on belül az URL fül alatt bemásolni a megfelelő szövegmezőbe a klónozáshoz.
A klónozást csak egyszer kell elvégezni egy számítógépen. Utána ha frissíteni szeretnénk, a lokális verziót, akkor csak a Fetch és a Pull parancsokat kell használni.
A Fetch parancs lekéri szerver repository állapotát, de nem változtat a lokális repository-n.
A Pull parancs letölti a szerver repository-t és frissíti a lokális verziót.
Stage, Commit, Push
Ha ezután dolgozunk a projektünkön akkor látni fogjuk, hogy a Desktop alkalmazás baloldalán megjelenik egy felsorolás a módosított fájlokról. Ha szeretnénk egy “mentett” verziót készíteni ezen változásokból, akkor Stage-elni és Commit-álni kell őket.
Egy file Stage állapotban van, ha a változtatás melletti jelölőnégyzetben szerepel a pipa. A GitHub Desktop automatikusan megjelöl Stage állapotba tesz minden módosítást.
Ha ezután kiadjuk a Commit parancsot, akkor a Stage állapotban lévő változások kerülnek bele ebbe az új mentett verzióba. A Commit-áláshoz mindenképp kell egy nevet adni a Commit-nak emellett opcionálisan leírást is rendelhetünk hozzá.
Egy Commit először mindig lokális lesz. Ahhoz hogy azt feltöltsük a szerverre a push műveletet kell alkalmazni.
A GitHub Desktop-ban a Pull, Fetch és Push gomb ugyanazon helyen helyezkedik el és a felsorolt parancsok közül egyszerre mindig csak egy látszik, az amire a repository adott állapotában épp szükség van.
Conflict és Merge
Fontos, hogy nem lehet Pull-olni, ha a letöltendő comit-ok közt van olyan fájl, amit már lokálisan módosítottuk, de még nem commit-áltuk. Ekkor mindenek előtt tegyük ezt meg. Utána kattintsunk a Pull gombra. Ekkor két lehetőség történhet:
- A konfliktust, ami a két különböző verzió közti különbséget jelenti a Git maga fel tudta oldani. Ez szöveges fájlok esetén gyakran így van. Ha egy fájlban a szerveren lévő változatban máshol történt a változás, mint a lokálisban akkor a két verzió automatikusan összefésülhető.
- Ha nem lehetséges a konfliktus automatikus feloldása, akkor úgynevezett Merge-et, manuális összefésülést kell alkalmazni. Ekkor eldönthető, hogy melyik változatot kívánjuk megtartani, vagy akár válogathatunk soronként a különböző verziók eltérő részei közül.
Visszaállítás korábbi állapotra
Ha még nem commit-áltunk egy módosítást, akkor mindig könnyedén vissza állhatunk a fájl előző állapotára. Ehhez a GitHub Desktop-on belül a jobb egér gombbal kell kattintani az adott fájlra. Az így Előhívott menüben a Discard parancsot használhatjuk a visszaállításhoz. Vissza lehet vonni bármilyen változást: törlést, létrehozást és módosítást.
A korábbi verzió egy projektnek a History fül alatt érhetők el. Ezek közül egy korábbira visszaállni a Reset parancssori paranccsal lehetséges ám ez nincs beépítve a GitHub Desktop-ba, ami egy egyszerű, kezdőbarát, de korlátozott funkcionalitású asztali kliens.
Nem lineáris fejlesztés
A Git támogatja különböző branch-ek azaz párhozamos fejlesztési ágak készítését is. Git-nek ezen funkcionalitásával ebben a leckében nem foglalkozunk.