Alapfogalmak
A Git az egyik legelterjedtebb verziókezelő alkalmazás a világon. Telepítése nem nagyon bonyolult. Windows, Linux, MacIntosh rendszereken is elérhető. A telepítését később Windowson bemutatom.
A GitHub egy olyan szerver (felhőszolgáltatás), amelyre bárki, bármikor ingyenesen létrehozhat csomagokat és azokat használhatja. A GitHub-ot pár éve megvásárolta az addigi működtetőktől a Microsoft, de ettől még ingyenes maradt a használata.
Repository (Repo, projekt) - Egy adatbázis, egy projekt. Ebben tároljuk tömörítve a projekt fájljait és azok különböző változatait.
A lokális repo a fejlesztői gépen található egy .git nevű rejtett fájlban a projekt könyvtárában.
Ha többen dolgoznak egy projekten, akkor van egy központi, távoli remote repository, amelyre a fejlesztési nap végével fel lehet tölteni a helyi repo tartalmát. Ehhez természetesen megfelelő jogosultságokkal kell rendelkezni.
Ha a fejlesztői gépen és / vagy egy szerveren több projektje van egy felhasználónak, akkor mindegyikhez tartozik egy-egy külön repository.
A repositoryknak két fajtája van:
private - csak regisztrált és megfelelő jogokkal rendelkező felhasználó férhet hozzá.
public - bárki hozzáférhet, ha tudja a tárolási helyét.
Ha egy projektből létrehozunk egy szerveren (pl GitHubon) egy repositoryt, akkor annak lesz egy nyitó állapota. Hogy dolgozni tudjunk létre kell hozni egy repot-t a szerveren.
Kommunikáció lokális és remote repository között
A fejlesztés során a változtatások a lokális repo-ban tárolódnak el. Ha többen dolgoznak egy fejlesztésen, akkor a fejlesztési nap elején érdemes a remote szerverről lehúzni (pull) a fejlesztés állapotát, és a fejlesztési nap végén pedig feltolni (push) a szerverre az állapotot.
A fejlesztést akkor érdemes feltenni a szerverre, ha annak az állapota bizonyos értelemben lezárult. Olyan fájlokat, amelyek tele vannak szintaktikai hibával ne tegyünk fel, mert más fejlesztők ismeretlen hibákba futhatnak bele.
A lokális és a távoli repository között a kommunikáció vagy SSH segítségével vagy HTTPS:// protokollon keresztül zajlik. Mind a két esetben titkosítottan közlekednek a fájlok.
Műveletek és parancsok
Clone - Klónozás - A szerverről letöltött teljes projekt a lokális (fejlesztői) gépre. Ezt akkor szokás, amikor egy új gépen hozzuk létre a teljes fejlesztendő projektet.
add - Ha egy repositoryba beteszünk egy új fájlt, akkor ezzel a paranccsal kell hozzáadni a nyilvántartáshoz.A fájlt tipikusan a fejlesztői gépen szokás hozzáadni a repositoryhoz.
commit - Menti a fejlesztői gépen történt változtatásokat a helyi Git nyilvántartásba. Ez még nem fogja feltölteni a szerverre a változtatásokat, hanem a helyi könyvtárban történnek meg a változtatások.
push - a változtatásokat feltölti a GitHub-ra.
pull - A távoli szerverről (GitHubról) letöltjük a változtatásokat a helyi gépre.
Branch-ek
A fejlesztés egy ága (szála) ! Ez a fogalom nagyon fontos! Amikor egy projekt állapotából elindítunk egy továbbfejlesztést, akkor egy fejlesztési szálat hozunk létre. Ha ugyanebből az állapotból egy másik tulajdonságot akarunk kifejleszteni, akkor az egy másik branch lesz. A branch-ek egymással párhuzamosan léteznek. A branch-ek egymástól függetlenül fejlődhetnek.
Amikor egy projektet létrehozunk, akkor létrejön egy alapértelmezett branch, a master branch. Ettől kezdve bármelyik állapotból létre lehet hozni egy branch-et, azaz minden egyes fejlesztési szálnak van legalább egy szülője. Korábban írtam, hogy a fejlesztői gépen történt változtatásokat egy commit utasítással viszünk fel a Git adatbázisába. Más szóval a commit hatására egy új állapot jön létre. A commit során írhatunk megjegyzést a parancshoz, amivel szavakban is jelölhetjük, hogy a commit mit rögzített.
Új branch létrehozásához egy meglévő commit-ból kell kiindulnunk. ez lesz az új branch kiindulópontja.
Ha egy pontból elindul két vagy több párhuzamos fejlesztés, azok mehetnek egymástól függetlenül ugyanannak a repository-nak különböző branch-eit folytatva.
Merge - Így hívják azt az eseményt, amikor két fejlesztési szálat - branch-et - össze akarunk fésülni. Ezt olyankor tesszük, ha a két branch egyfajta végállapothoz ért és az eredeti projektbe minden új fejlesztést be akarunk építeni.
Branch-ek létrehozásának tipikus esetei.
Amikor a fejlesztésünk elér egy valamennyire véglegesnek tekinthető állapotot, akkor az utolsó commit lehet branch-ek kiindulópontja. Például egy alkalmazás elérte a v1.0 állapotot. Ez lesz a master állapot.
Kiderül, hogy az állapotban találtak valami hibát, amit javítani kell. Az ilyet hotfix-nek hívják. Ezt egy hotfix nevű branchban indítja el az egyik fejlesztő. Közben a fejlesztők folytatják a v1.0 valamilyen tervezett, de nem befejezett fejlesztését. Ez az eredeti fejlesztésnek egy developer (fejlesztői) branch-e lesz. A fejlesztői ág több commit-on keresztül halad előre, majd az eredeti ágba beleépítik a hotfix ág eredményét. A developer ágból egy bizonyos ponton elindulhat párhuzamosan kettő vagy több új tulajdonság fejlesztése (feature1, feature 2) párhuzamosan. Egy idő múlva a feature1 ág elkészül, a feature2 ágról kiderül, hogy nem érdemes tovább folytatni bármilyen okból. A developer és a zon belül a feature1 ágból létrejön a release ág, amely más a kibocsátás előtti tesztelési ágat jelöli.
A release ágon indulnak a hibajavítások. A v1.1a (alfa), belső teszt állapot, amelyet a fejlesztők és a cég belső tesztelői javítanak. Miután már nem talál a cég több hibát, a fejlesztést v1.1b (béta), nyilvános teszt állapotúnak nyilvánítják és külső tesztelők tesztelik. Ha az így talált hibákat is kijavították, akkor jönnek a kiadás előtti állapotok (v1.1RC1, az v1.1RC2, RC=Release Candidate), amelyekben már csak apróbb szépséghibákat javítanak. A fejlesztést beépítik a master ágba és kész az új verzió v1.1.
Ez az új változat lehet egy új fejlesztési ciklus kiindulópontja, de lehetséges, hogy egy új verziókon átívelő nagyobb fejlesztésbe a v1.1-et merge-elem és tovább viszem a 2.0 állapot elérése felé.
Ez egy lehetséges fejlesztési rajz. Ahol a fejlesztés szétválik, ott új fejlesztési ágak jönnek létre. Ahol két ág találkozik ott új merge jött létre.
A Master ág általában a production, azaz a kiadásra érett változatot jelenti.
A production ágból jöhet létre a hotfix (hibajavítás) ág, a developer ág, ami a fejlesztés fő irányát jelenti. A develop verziót általában nem fűzik be a master verzióba, hanem készül egy release verzió is. A release verzió lesz v1.1a, v1.1b, v1.1RC1, v1.1RC2. Ha a release verzió stabil, akkor kerül vissza a master ágba.
Konfliktus
Olyankor jön létre, amikor branch-eket merge-ölöm vagy a szerverről lehúzok egy branch-et. Ha a művelet észreveszi, hogy egy fájlnak ugyanaz a sora kétféle módon változott, akkor a fejlesztőt figyelmezteti (reject) értesíti a Git, hogy javítsa ki a konfliktust. A későbbi push-oló kapja a figyelmeztetést. Le kell töltenie (pull) a szerverről a változatot, lokális gépen javítania, majd utána commit-olhat és töltheti fel az új változatot. Ilyenkor a későbbi commit, illetve az a fejlesztő, aki később húzza le a központi repoból az állományt kap egy figyelmeztetést (reject), hogy konfliktus van. Ezt neki kézzel kell feloldania.
Remote és lokális branch-ok
A fejlesztői gépen vannak lokális és remote branch-ok is. A lokális branch-ok tartalmazzák a teljes fejlesztői projektet fájlokkal együtt, míg a remote branch-ok csak hivatkozásokat a távoli repo fájljaira.
A fejlesztés során a commit a lokális branch-okat teszi véglegessé. A remote branch-okba a fájlok tényleges feltöltése csak a push utasítással hajtódik végre.
Saját adatok beállítása
A Git commit parancsa eltárolja a parancsot kiadó felhasználó nevét, email címét, dátumot és egyéb információkat. ezeket az információkat az alábbi parancsokkal lehet beállítani:
git config --global user.name ”Név”
git config --global user.email ”e-mail” .gitignore fájl
Ez a fájl tartalmazza a projektben lévő olyan könyvtárak és fájlok listáját, amelyeket nem kell verziókövetni. Ilyenek lehetnek képek, futtatható fájlok, debug információk, parancsfájlok, stb. A fájl egy egyszerű felsorolást tartalma, ahol egy sor egy definíciót jelent. Például:
[Dd]ebug/
# az összes .txt kiterjesztésű fájl kihagyása
*.txt
# obj könyvtár kihagyása
obj/
# config.c fájl kihagyása
config.c
# lib/main.c fájlt kövesse, nem lesz a kihagyott fájlok között
!lib/main.cAmint látható dzsókerek és egyéb megszokott jelölések is használhatók. A # jellel kezdődő sorok megjegyzések