A GIT és a Delphi

Egy munka kapcsán vizsgáltuk, hogy a Delphi hogyan használható együtt a Git verziókezelővel.

A két eszköz

A Git

A Git egy nyílt forráskódú elosztott verziókezelő szoftver, vagy másképpen egy szoftver forráskód kezelő rendszer, amely a sebességre helyezi a hangsúlyt. A Gitet eredetileg Linus Torvalds fejlesztette ki a Linux kernel fejlesztéséhez. Minden Git munkamásolat egy teljes értékű repository teljes verzió történettel és teljes revízió követési lehetőséggel, amely nem függ a hálózat elérésétől vagy központi szervertől. ( forrás: Wikipédia)

A Delphi

A Delphi az Embarcadero (régen Borland Software Corporation - CodeGear) cég Windows grafikus felületen futó Object Pascal alapú negyedik generációs (4GL) programozási nyelve.
A hatékonyabb programfejlesztéshez vizuális fejlesztőkörnyezetet is tartalmaz, mely a VCL, a vizuális komponensek könyvtára segítségével kifejezetten magas szintű és hatékony fejlesztést tesz lehetővé. Ugyanez a könyvtár és fejlesztési felület az alapja a Borland C++ Builderének is. (forrás: Wikipédia)

A javaslat: GIT Bash

A GIT Bash program egy nyílt forrású GNU licences eszköz, melyet ezért bárki szabadon használhat. A program legfrissebb telepítője innen letölthető. A telepítés során érdemes csak a bash parancskezelő telepítését választani.

A GIT Bash Delphi melletti használatához a Delphiben semmit nem kell beállítani, konfigurálni.

Önálló munka:

Egy új repository (projekt) indításához a

git init

parancsot kell kiadni, praktikusan abban a könyvtárban ahol a Delphi projekt fájl (dpr) is van. A repository ekkor még teljesen üres, egy fájl változását sem követi a GIT. A projekt meglévő (és esetleg új) fájljait a

git add <fájlnév>

paranccsal vonhatjuk be a verziókövetendő elemek listájába. A git status parancs megmutatja, hogy mely követett fájlokban van változás (ha van), illetve, hogy az alapkönyvtár mely fájljait nem követi (még) a GIT. A fájlok változásait a git diff vagy git diff <fájlnév> parancs segítségével nézhetjük meg. A végrehajtott módosításokat a

git commit -a

parancs menti el a repositoryban. Később ezekre a 'mérföldkövekre' vissza lehet lépni vagy az ekkor végrehajtott módosításokat megtekinteni. A visszalépés kétféle lehet, maradandó, vagy átmeneti. A maradandó visszalépés (git reset --hard HEAD^) minden fájlt visszaállít a megadott állapotra (jelen esetben az utolsó előttire), ÉS törli a repository minden mentett állapotát ami ez után történt. Az átmeneti visszalépés ( git reset --soft HEAD^) is visszaállít minden fájlt a megadott állapotra, de nem törli a repository mentett állapotait. Ilyenkor a git status illetve git diff parancsok olyan állapot változást mutatnak, mint ha mi magunk kézzel visszamódosítottuk volna a fájlokat. A parancsban szereplő állapotok a következőek lehetnek:

HEAD	: Az utolsó még mentett állapot. (közvetlenül az utolsó commit után)
HEAD^	: Az utolsó előtti mentett állapot.
HEAD~(2	3	n)	: A megadott számmal korábbi állapot.

A fenti 5 parancs segítségével egy egyszemélyes, lineáris fejlesztés végigvihető.

---

Elágazás (branch):

A fejlesztés során szükség lehet több fejlesztési ágra is, melyekben mondjuk 1-1 új funkció kerül kidolgozásra (a fővonalon kívül) majd ha a fejleszés stabil, az eredmény beolvasztásra kerülhet a fővonalba. Új ágat kétféleképpen is létrehozhatunk. A git checkout -b <branchnév> parancs segítségével a létrehozáson túl a megadott branchnév lesz az aktuális, éppen szerkesztett ág. A git branch <branchnév> parancs ugyanúgy létrehozza a megadott branchnév ágat, de az aktuálisan szerkesztett ágat nem módosítja. A git branch parancs megmutatja az összes ágat, csillaggal (*) megjelölve az aktívat. Az ágak között a git checkout <branchnév> parancs segítségével mozoghatunk. Természetesen az átváltással együtt a forrásfájlok is a megadott ág aktuális állapotára módosulnak.

Ha készen vagyunk a rész-fejlesztéssel, és szeretnénk összeolvasztani a két ágat, a git merge <branchnév> paranccsal tehetjük meg. Ennek hatására a branchnév ágat az aktuális ágba olvasztja a GIT. Amennyiben az összeolvasztás során konfliktus merül fel a két kód között (ugyanazon a helyen mindkét kód változott) erről figyelmeztetést ad a parancs. Ezt mindenképpen nekünk, kézzel kell feloldanunk, majd git commit -a val véglegesítenünk.

A fölöslegessé vált ágat a git branch -d <branchnév> paranccsal lehet törölni. Ha egy olyan ágat szeretnénk törölni, ami végül nem került beolvasztásra a főágba, de már szükségtelen, a git branch -D <branchnév> parancsot kell kiadni.

---

Csoportmunka:

Gyakran van szükség arra, hogy egy programot több ember több helyről fejlesszen. Ekkor többnyire egy központi adatbázis (repository) tárolja a kódot, mindenki innen tölti le az éppen aktuális verziót, végez rajta módosításokat, majd tölti vissza ezeket. Egy ilyen központi adatbázisban követett munkához úgy lehet csatlakozni, ha először letükrözzük magunkhoz az egészet.

git clone <repository>

Egy távoli repository megadásának egy lehetséges módja: ssh://<felhasználónév>@<gépnév><a_repository_teljes_elérési_útja>

Ez nálam pl így nézett ki: ssh://atus@impetus/home/atus/melo/git/dummy_file/

A git fetch <repository> paranccsal lehet elhozni a napi munka előtt a távoli adatbázis éppen aktuális állapotát, a git pull <repository> val pedig azonnal aktualizálásra is kerül.

A helyi módosításokat a

git push <repository>

paranccsal lehet feltölteni a központi adatbázisba. A --mirror kapcsolóval gyakorlatilag a helyi adatbázist lehet rátükrözni a távolira, a --dry-run kapcsolóval pedig szimulálhatjuk a feltöltést, hogy jól futna-e le. A -f kapcsolóval elérhetjük, hogy mindenképpen felülírásra kerüljön a távoli adatbázis, (ezzel esetleg mások munkáját eltörölve) ezért ezzel a kapcsolóval vigyázva bánjunk.

Csoportban dolgozva óhatatlanul elő fog fordulni az az eset/állapot, hogy valaki előttünk tölt fel módosítást a szerverre, így a nálunk található verzió nem lesz a legfrissebb amikor fel akarjuk tölteni a változtatásainkat. Erről egy hibaüzenetet kapva értesülünk: ! [rejected] master → master (non-fast forward)

---

Konfliktus feloldása:

Ha valaki már töltött fel új verziót mialatt mi dolgoztunk, a feltöltésünk az alábbi hibaüzenettel meg fog hiúsulni:

To <repository>
! [rejected] master → master (non-fast forward)
error: failed to push some refs to '<repository>'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again. See the 'non-fast forward'
section of 'git push --help' for details.

A problémát az alábbi kétt módon lehet feloldani:

1a.) git pull <repository>
[A pull automatikusan megcsinálja azt a merge-et, amit a push nem. Ha ugyanott van módosítás,
akkor minkettőt beteszi és a használónak kell belőle feltölthető kommitot csinálni. Ezt közli is a pull]
1b.) ellenőrzés, hogy mit csináltak alattunk/előttünk
1c.) git push <repository>

2a.) git fetch <repository>
2b.) git merge FETCH_HEAD
2c.) ellenőrzés, hogy mit csináltak/változtattak alattunk/előttünk
2d.) git push <repository>

---

Git (Bash) GUI

A Git Bash nem csak egy parancs-sori eszközt telepít, hanem egy grafikus felületet is. Ez a Start menüből érhető el Git GUI néven. A GUI-n ugyanazokat a műveleteket tudjuk elvégezni, mint parancs-sorban, csak itt kattintgatni kell gépelés helyett. A teljes felület így néz ki:

A felület nem frissül automatikusan, tehát ha változtattunk egy fájlon, addig nem látjuk, hogy mi változott, amíg ennek vizsgálatát (változott-e valami) nem kérjük. Ezt az [F5] gomb segítségével vagy a [Keresés újra] gomb/menü kiválasztásával érhetjük el. A "Kiválasztatlan változások" oszlopban a követett és nem követett fájlok látszódnak. Előbbiek kékkel csíkozott ikonnal jelennek meg, utóbbiak üres lapként. A "Kiválasztott változások" oszlopban azok a fájlok látszanak zölden kipipálva melyeket kommitálásra jelöltünk ki. A nem követett fájlokat csak a "Commit" menüben tudjuk hozzáadni a változásokhoz a "Kiválasztás kommitolásra" lehetőséggel.

Az elágazással kapcsolatos műveletek a Branch menübe kerültek, az összevonást kivéve (Merge), ami külön menüt kapott.

A karakteres felülethez képest többlet, hogy a "Repó" menüben lehetőségünk van a teljes repository illetve annak egy ágának vizualizálására.

A vizualizálásban látjuk, hogy ki, mikor, mit kommitolt a kódban, milyen elágazások és összeolvadások voltak.

-- KadarAttila - 2010-03-10