Elérkezett az idő amikor nem halogathattam tovább és bele kellett vetnem magam a verziókezelő rendszerek csodás világába, méghozzá kicsit szűkítve a kört: a Git lett a kiszemelt eszköz. Mint már sokszor most is a "mi a fenéért is nem foglalkoztam vele eddig?" érzés közepedte jöttem rá, hogy a ez egy remek cucc, melyet használni kell.
Mire is jó a Git? Ez egy offline fejlesztésre (is) kihegyezett verziókövető rendszer. Nem szükséges neki folyamatos élő kapcsolat és elég jól elvan a szerverrel való folyamatos kommunikáció nélkül is. A segítségével az aktuális projektünk forráskódján történt változásokat követhetjük nyomon, elágaztathatjuk, kommentelhetjük, visszaállíthatjuk.
Egyéni fejlesztőknek hol ebben az előny? Tegyük fel, hogy dolgozol egy webshopon. Minden nap szépet commitolod a változásokat így minden nap meg tudod mondani, hogy melyik nap mi változott. Aztán jön a megrendelőtől egy kérés: Mi lenne ha facebook integráció is lenne az oldalban? Semmi gond, hiszen létrehozhatsz egy új Branch -et azaz szálat. Ebben elkezded megírni, sőt még be is fejezed a módosítást. Megrendelőnk viszont rájön, hogy ez így neki mégsem tetszik vissza az egész. Ebben az esetben visszatérhetsz az eredeti vonalhoz, és a projekt eredeti állapotát egy pillanat alatt visszahozhatod úgy, hogy "hátha kell" alapon akár az új verzió is megmaradhat.
Csapatban dolgozva mégtöbb előnye jön ki a rendszernek, hiszen többen úgy tudtok egyazon projekten dolgozni, hogy a módosításokat a rendszer nyomon követi, összefésüli. Mutatja, hogy ki mikor mit változtatott. Hasznos? Naná!
A Git telepítésére most nem térek ki, legyetek kreatívak és guglizzatok okosan. :) Mivel a Git alapvetően konzolos dolog ezért telepítés után vagy indítsatok egy Terminált, vagy Windows alatt egy start menü/cmd kelleni fog.
git config --global user.email "mail@cimem.hu"
A fenti két parancs segítségével beállíthatjuk az alapvető adatainkat, így minden általunk elkövetett műveletnél a Git tudni fogja, hogy ki kezdeményezte. Ezt csak egyszer kell beállítani.
Következő lépésben be kell lépni abba a könyvtárba aminek a tartalmát szeretnénk nyomonkövetni. A példámban ez a "project" nevű mappa lesz.
git init
A git init egy rejtett .git nevű mappát fog létrehozni a project mappán belül. Ezzel egyelőre ne törődjünk, hiszen a módosításainkat itt tartja a rendszer. A mappa létrejöttével gyakorlatilag indítottunk egy új git adatbázist. Most ha ebben a könyvtárban létrehozunk egy fájlt/módosítjuk a tartalmát, átnevezzük stb arról a git már tudni fog, azonban automatikusan nem ment el minden egyes változást!
A változások elmentését Commit -olásnak hívjuk és csak azok a fájlok commitolódnak amikre kiadjuk a parancsot.
A git add . parancs a könyvtár teljes tartalmára beállítja a figyelést, azaz minden fájlt hozzáad.
Minden fájlt commitol. Ilyenkor meg fog nyílni egy szövegszerkesztő, ahol egy rövid (vagy hosszú) leírást adhatsz meg arról,hogy mi is változott a projektben. Miért jó ez? Mert ha 1 hónap múlva visszanézed a commitokat akkor gőzöd sem lesz róla, hogy a mai és a tegnapi között mi a különbség. Természetesen a módosításokat látni fogod, de egyszerűbb egy 2 soros komment alapján megállapítani, mint végignézni a fájlok változásait. Másik lehetőség a commitolásra a:
Ahol a szövegszerkesztős részt megúszhatjuk, és a -m paraméter miatt a megjegyzés inline beállítható.
Akkor sincs gond, ha valamit elírtál a megjegyzésben, vagy kimaradt volna egy fájl:
Commitoláskor az adatok nem töltődnek fel automatikusan a szerverre mindössze helyileg eltárolódik mint egy verzió. A feltöltéshez a git push parancs kiadása is szükséges. Ehhez először is állítsuk be a távoli szervert:
Ahol az user a git user, a server.hu a távoli szerver címe, a project helyére pedig a projekt neve megy. Ezzel gyakorlatilag közöltük a gittel, hogy ha az origin alatt az user@server.hu:project.git repo-t értjük.
Az origin -ben meghatározott szerverre feltölti a master branch -et. Ha másikat szeretnénk feltölteni akkor értelemszerűen annak a nevét kell beleírni. A master branch az alapértelmezett.
Megmutatja a commitok történeteit. Minden commit kap egy kódot, például c333f7d4d02468eeeef39739ac79f30720c95c94. Ennek a segítségével azonosíthatjuk a későbbiekben. Hogyan is értem ezt?
Tegyük fel, hogy véletlenül törölted a "proba" nevű fájlt és commitoltad is. Ebben az esetben nem kell kétségbe esned, hiszen annyi a feladatod, hogy a proba fájlt visszahozod az utolsó commitból ahol még elérhető volt. Ehhez először is meg kell keresni, hogy melyik az utolsó ahol még elérhető a fájl:
Ez egy a fent említett sh1 kulcsot fog visszaadni ami egyértelműen azonosít egy verziót. Most:
A kulcs helyére értelemszerűen mindenki azt írja amit az rev-list visszaadott válaszul. A checkout vissza fogja nekünk állítani a proba fájlt.
Persze a checkout nem csak 1-1 fájl visszaállítására jó, hanem képes minket visszarepíteni az időben, hogy megnézhessük, miként is állt a projekt mondjuk egy hónapja:
A projektünk tartalmát átállítja a c333f... -nek megfelelő állapotba.
Az általános lehetőségek közül már csak az az eset maradt hátra, hogy mi történik ha többen dolgoztok egy projekten. Ebben az esetben bár más push-olhat, de mivel mindenki a saját gépén dolgozik ezért lokálisan nem fognak automatikusan befrissülni a fájlok. Erre az esetre való a pull parancs.
Ami frissíti a fájlokat úgy, hogy lokálisan is megjelenjenek azok a változások amik eddig csak a szerveren voltak elérhetőek, vagyis ha a readme.txt-be valaki beszúrt egy új sort akkor az a sor megjelenik lokálisan is.
Érdekesség, hogy tömörített formában is kinyerhető bármelyik checkout. Linux alatt például:
Hasznos funkció továbbá, hogy nem kell a checkoutok teljes nevét kiírni, csak annyit amennyi már elég az egyedi azonosításhoz. A legtöbb parancs megpróbálja kitalálni, hogy melyikre is gondoltunk, azaz a
pont ugyanolyan hatásos lesz mintha kiírtuk volna végig. Ha túl kevés karaktert adtunk meg az egyedi azonosításhoz akkor természetesen hibaüzenet szól a dologról.
