Tuesday, July 26, 2011

Gittegylet meg a Yii - avagy Yiiki 2.0 (3. rész)

Akik még mindig olvassák ezt a cikk sorozatot, azoknak KÖSZI. Akik csak most probálkoznak bekapcsolódni, azoknak mindenképp ajánlom az előző két rész elolvasását hiszen ott ismerkedtünk meg olyan dolgokkal mint a yiic parancs, Git forráskezelő és a Gii kódgeneráló.

Az előző részt ott fejeztük be, hogy a Gii segítségével elkészítettük a Page modell osztályunkat a pages táblához. Ha most megnézzük, hogy hogy áll a forrásunkat (git status) akkor láthatjuk, hogy egy Page.php file jött létre a protected/model/ mappán belül. Ezt hozzá is adhatjuk a szokásos git add paranccsal. (A Git-ről itt van egy leírás magyarul a BME oldalain. Ebben a cikk sorozatban már csak a végén vesszük elő mégegyszer, amikor publikáljuk a programunkat).

CRUD

Azzal, hogy elkészítettük a Page modellünket, még semmi, böngészőben látható eredményt nem sikerült produkálnunk. Itt jön a CRUD a képbe,

Create - Létrehoz
Read - (Be)olvas
Update - Frissít
Delete - Töröl

Most megint vegyük elő a varázságyúnkat (Gii) és belépés után kattintsunk a Crud Generator linkre. Ha minden igaz, egy két mezős form-ot kell kapnunk, ahol valójában elég csak az első mezőt kitölteni a Model Class-t azaz Modell Osztáy-t, a Controller ID-t a Gii magától kitalálja. Jó mi? (Megj: a Base Controller Class és a Code Template útvonal is átírható, így ezek segítségével ha akarjuk teljesen újraírhatjuk a Gii viselkedését.)

Tehát írjuk be a Model Class-be, hogy Page és nyomjuk meg (csak egyszer!) a Preview gombot. Ha valami ilyesmit látunk akkor örülhetünk:



Itt már lényegesen több file fog elkészülni mint a modell létrehozásánál. Láthatjuk, hogy maga a Controller (vezérlő) is elkészül majd, a view/page mappa is, ahol a rendszer fogja tárolni a szükséges nézet file-okat (create.php, update.php, view.php stb). Ha minden OK, nyomhatunk a Generate-ra.

A programunk jelenlegi állapotában már mindenre kész. Tudunk oldalakat listázni, készíteni és törölni. Hogy megbizonyosodjunk róla, böngészőnkkel látogassuk meg a következő URL-t:

http://localhost/index.php?r=page

Na de mi nem elégszünk meg ennyivel, hiszen egy igazi Wiki-t szeretnénk készíteni. Jöhet a testreszabás ...

Testreszabás

Beviteli form módosítása

Ha most probálnánk egy Page-t azaz Oldalt készíteni (http://localhost/index.php?r=page/create), akkor azonnal észlelnénk, hogy a beviteli form-on egy csomó olyan mező van, amit nem szeretnénk kézzel minden egyes alkalommal kitölteni, illetve elvárnánk a programunktól, hogy saját maga töltse ki. Ilyen például a created vagy a revision mező.

Módosítsuk is a form-unkat valahogy így:



A Page Modell Szabályainak Beállítésai

A Page (Oldal) modellünkre is ráfér egy kis farigcsálás. Ugyan Gii többnyire kitalálta, hogy milyen szabályokat hozzon létre a különböző form mezőkhöz, a gondolatolvasástól azért még messze van.

Mi ugyanis szeretnénk, ha az Oldalunk címébe csakis betűk, számok, vagy aláhúzás jel szerepelhessen. (Egy jó kis bővítés lenne, ha a programunk automatikusan felülírná a bevitt a címet, de az példa kedvéért itt egy szabályt hozunk létre)

protected/models/Page.php



Az itt használt szabályok elég egyértelműek, de ha valaki jobban bele szeretne mélyülni itt olvashat róluk bővebben: http://www.yiiframework.com/doc/cookbook/56/

Itt még azt is megfigyelhetjük, hogy hogyan kell a programunkat magyarul tanítani ;)

A beforeSave() and save() modell függvények használata/felülírása

A modelljeink, amik a programunkban az adatbázis lekérdezéseket kezelik, mindenféle függyvényekkel fel vannak fegyverkezve, hogy nekünk ne kelljen védőkesztyű nélkül SQL-kódban kotorászni. Az egyik ilyen függvény a save() (mentés) és hű csatlósa a beforeSave() (mentés elött elment). A save() egy adatbázis rekordot köteles elmenteni vagy felülírni.

A pages adatbázis táblánkban van egy olyan mező, hogy created (készítve), ami egy dátum mező. (a példánkban UNIX Timestamp-et használunk!) Ez a mező tartja nyilván, hogy az adott oldal mikor lett készítve/felülírva. Ugyan használhatnánk a save() függvényt arra, hogy ezt az értéket beállítsuk, a példa kedvéért ezt a beforeSave()-vel oldjuk meg.

(Az fontos, hogy itt a szülő beforeSave()-jével térjünk vissza, return parent::beforeSave() )

protected/models/Page.php



Néha előfordul, hogy még a form mezők ellenőrzése elött szeretnénk beállítani valamilyen értéket, ezt a beforeValidate() funkcióval tehetjük meg.

A save() függvénynél már kicsit más a helyzet. Először vegyük sorra, hogy mit is szeretnénk a programunktól, amikor elmentünk egy oldalt. Ha minden igaz, említettük az elején, hogy a jövőben szeretnénk egy revert opciót, ami annyit jelent, hogy az odalalainkat, ha akarjuk, visszaállíthatjuk egy korábbi változatba. Ezt többféle módon is meg lehet valósítani, de talán a legrövidebb megoldás, ha az oldalakat mindig újként mentjük el, és csak növeljük a revision azaz verziószámot.

protected/models/Page.php



A Yii modell osztálya olyan finomságokkal lát el bennünket, mint például a $this->isNewRecord ami egyszerűen megmondja nekünk, hogy most egy új rekordról van e szó, vagy csak felülírunk egyet. Mi persze tudjuk, hogy nekünk arra van szükségünk, hogy minden egyes oldal újként legyen elmentve, tehát ha az oldal nem új, akkor egyszerűen gyártunk egyet ami a $newpage->attributes=$this->attributes segítségével felveszi az eredeti oldal értékeit.

Még annyit érdemes megjegyezni, hogy ha a save() függvényt false paraméterrel hívjuk meg, akkor az ActiveRecord-ban beállított szabályai nem vonatkoznak az adott rekordra.

Az Oldalak-at lekérő SQL módosítása és a hozzá tartozó Nézet (View) beállítása

Ha most néznénk meg az Oldalak listáját, azt vennénk észre, hogy programunk, az egyes Oldalakhoz tartozó összes reviziót megmutatja. Ez ideáig rendben is van, hiszen minden egyes változatot "új"-ként mentettünk el, azonban ez elég zavaró lehet, meg bugyután is néz ki. Ha eddig még nem említettük volna, majd minden Controller osztálynak van egy úgynevezett actionIndex()-je ami az alapértelmezett függvény. Jelen esetünkben ez szolgáltatja az Oldalak listáját. Keressük is meg a PageController-ben és módosítsuk a következők szerint:

protected/controllers/PageController.php - actionIndex()



SQL-ben valamennyire jártasabbak egyből kiszúrhatják, hogy mi is történik. Itt létrehozunk egy úgynevezett CDBCriteria() osztályt aminek segítségével különböző SQL paramétereket állíthatunk be, és ez által módosíthatjuk a lekérdezéseinket, ami ebben az esetben az Oldalak csoportosítását jelenti a title azaz cím szerint, és rendezést a létrehozás dátuma szerint.

Az alábbi file-okat pedig módosítsuk izlésünk szerint (illetve az én izlésem szerint). Ha még emlékszünk, a PageController-t kicsit átalakítottuk, hogy az adott Oldal azonosító ID-ja helyett a title mező értékével dolgozzon. Ez nagyon szép és jó, de a program többi részét is kicsit át kell alakítanunk. Ilyen például az actionCreate() és actionUpdate() funkciókban használt redirect() ami azt a célt szolgálja, hogy bizonyos események után böngészőnket egy meghatározott oldalra küldje.

protected/controllers/PageController.php



A következő file-ok pedig a megjelenítést szolgálják ...

protected/views/page/_view.php



protected/views/page/view.php



Jajj de jó, már lassan készen is vagyunk. Mondjuk a megjelenített oldal egyáltalán nem úgy néz ki mint egy igazi Wiki oldal. A következő részben megnézzük, hogyan használjuk a Yii-be alapból beépített MarkDown értelmezőt, hogy megússzuk a sok str_replace()-t ;)

Mivel a Wiki alkalmazásunk elég speciális (ID-k helyett a cím alapján találunk meg egy-egy Oldalt), ezért a Page vezérlőnkben elég sok minden változott,úgyhogy a teljesség kedvéért ide betettük az egész osztályt.

Tuesday, July 19, 2011

Gittegylet meg a Yii - avagy Yiiki 2.0 (2. rész)

Az első részben elkészítettük a Yiiki 2.0 alkalmazásunk alapjául szolgáló keretünket a Yii segítségével és megismerkedtünk a Git forráskezelővel. Ebben részben először kicsit átírjuk a belépő index.php file-t, elkészítjük az adatbázisunkat a Yii-be épített migráció kezelővel, majd létrehozzuk a Modell osztályunkat Gii-vel, a Yii kódgeneráló varázságyújával (tényleg az).

Amikor az alkalmazásunkat létrehoztuk a yiic paranccsal, maga a Yii készített nekünk egy konfigurációs file-t a protected/config/ alatt main.php néven. Természetesen használhatnánk ezt a file-t úgy ahogy van, de igazából nem szerencsés a rendszer kofigurációs adatait a forráskezelő alá tenni, hiszen a beállítások mások lesznek különböző környezetek alatt (pl. fejlesztői, éles stb), sőt az adatbázis kapcsolathoz szükséges felhasználó és jelszó is ebben a file-ban van. Erre a problémára természetesen többféle megoldás is lehet, itt csak egyet mutatunk be.

Első lépésként másoljuk a protected/config/main.php -t development.config.php -ra:

$cp protected/config/main.php protected/config/development.config.php

Ha most git stat-tal megnéznénk, hogy hogyan is áll a forráskódunk, látnánk, hogy a git azt jelzi, hogy van egy új file-unk. Mi persze nem szeretnénk a konfigurációs file-t a forráskezelő alá helyezni, ezért tegyük is a .gitignore file-ba.

Belépő script módosítása

Most kedvenc kódszerkesztőnk segítségével (ami nyilván VIM), nyissuk meg az index.php file-t és módosítsuk a követlkező képpen.



Ezzel csupán azt értük el, hogy amikor ha a YII_DEBUG konstanst true-ra állítjuk, akkor programunk a development.config.php-t fogja betölteni, egyébként pedig a production.config.php-t amit majd később az éles, mindenki által elérhető szerveren fogunk használni.

Adatbázis Migrációk

Migrációkról más esett szó ezen a blogon, igaz akkor még egy különálló modulként kellett installálni, de szerencsére ez mára már a Yii, pontosabban a yiic része. Röviden arról van szó, hogy könnyebb hordozhatóság kedvéért az adatbázis táblákat migrációs osztályok és tömbök segítségével készítjük el.

Jelenleg, mivel az eredeti main.php konfigurációs file-t másoltuk át development.config.php-re, adatbázisunk még mindig a testdrive.db. Ezzel sajna nem sokra megyünk, úgyhogy állítsuk is át valami másra, pl:

'components' => array(
...

  'db'=>array(
    'connectionString' => 'sqlite:'.dirname(__FILE__).'/../data/yiiki2.db.sqlite',
  ),

...
),

Ugyanezt tegyük meg a protected/config/console.php file-ban is, hiszen a migrácókat készítő yiic parancs innen olvassa be az adatbázis hozzáférési adatait.


Már nincs más hátra mint előre, készítsük el a táblánkat az adatbázisban (a yiiki2/ mappában adjuk ki a következő parancsot):


$./protected/yiic migrate create pages_tabla_letrehozasa

Yii Migration Tool v1.0 (based on Yii v1.1.8)
Create new migration '/var/www/yiiki2/protected/migrations/m110710_033230_pages_tabla_hozzaadasa.php'? [yes|no]



Mondjuk neki, you 'y' (igen) és ha minden igaz, akkor egy a megerősítő "New migration created successfully." - üzenetet kapjuk vissza. HURRÁ! Ezzel egy új file került létrehozásra a protected/migrations alatt valami hasonló névvel: m110710_033230_pages_tabla_hozzaadasa.php. Itt az 'm' csak azt jelzi, hogy ez egy migráció, az utána következő számsorozat pedig a migráció sorszáma, majd a név amit megadtunk.


Nyissuk is meg ezt a file-t és módosítsuk a következők szerint:



Ezzel elkészítettük az új migrációs lépést, de még le is kell futtassuk, hogy a táblánk magában az adatbázisban is megjelenjen:


$ ./protected/yiic migrate


Yii Migration Tool v1.0 (based on Yii v1.1.8)


Creating migration history table "tbl_migration"...done.
Total 1 new migration to be applied:
    m110710_033230_pages_tabla_hozzaadasa


Apply the above migration? [yes|no]


Ez csak azt jelenti nekünk, hogy ez a Yii Migrációs Eszköz 1.0-ás változata, a Yii 1.1.8-ra épül és jelenleg 1 migrációs lépést lehet végrehajtani a pages_tabla_letrehozasa -t. Mondjuk neki, hogy 'y' vagy 'yes'. Ha miden jól sikerült valami hasonlót kell, hogy lássunk:


*** applying m110710_033230_pages_tabla_hozzaadasa
    > create table pages ... done (time: 0.201s)
*** applied m110710_033230_pages_tabla_hozzaadasa (time: 0.054s)
Migrated up successfully.


Ez kb. annyit jelent, hogy minden OK. Csak egy megjegyzés - ugyan ebben a cikkben nem fogunk többet a migrációkkal foglalkozni, érdemes őket tanulmányozni, hiszen nagyon sok mindenben segítséget nyújthatnak. Páldául ha az idegen kulcsokat (foreign-keys) a táblák között megfelelően beállítjuk, Yii automatikusan összeköti Modell osztályainkat a használandó BELONGS_TO, HAS_ONE stb. kapcsolatokkal. Persze ezt kézzel is be tudjuk állítani, de mennyivel egyszerűbb amikor nem kell gépelni ... elvégre is lusta programozók lennénk, vagy mi fene.

Mivel jelenleg egyedül programozunk ez a lépés elhanyagolható, de a példa gyakorlás kedvéért érdemes magát az új migrációs lépést egyből a forráskezelő alá tenni, hogy "csapattársaink" is frissíthessék az adatbázisaikat. Használjuk a git status-t és a git add-et és persze a git commit-ot :)

Gii Gii Gii Giiiiiiiii

Ha annak idején a yiic-et a Yii varázspálcájának hívtuk, a Gii-t joggal nevezhetjük varázságyúnak. Egy nagyon egyszerű de szexi, böngészőn keresztül futtatható kód generáló eszközről van szó, ami szépen felgyorsítja a programozást. Azoknak akik meg nyöszörögnek (mert akadnak páran), hogy túl sok a varázslás meg a mágia, vissza lehet menni saját keretrendszert barkácsolni. Sok szerencsét.

A Gii ugyan együtt érkezik a rendszerrel de biztonsági okok miatt alapból ki van kapcsolva. Nyissuk meg a konfigurációs file-unkat és keressünk rá a gii szóra a modules tömb környékén. Ha megvan, nyilván szedjük ki a /* ... */-t, és állítsunk be egy jelszavat (password), mondjuk: giiros -ra (vicces mi? haha).

Most látogassuk meg a Gii eszközt egy böngészőben ezen a URL-en: http://localhost/yiiki2/index.php?r=gii. Ha mindent jól csináltunk akkor a Yii Code Generator-nak kell megjelennie (ez a Gii) és egy jelszót bekérő form mezőnek. Büszkén írjuk is be a jelszavunkat (tudod, a giiros). Itt már láthatjuk is a köszöntő oldalt ami röviden annyit közöl, hogy a Kód Generáló segítségével gyorsan felépíthetjük a Yii alkalmazásunkat. És tényleg ... Elsőként tanácsos a Modell-t elkészítenünk, hiszen ez köti össze az adatbázisunkat a programmal. Klikkoljunk is rája:



A tablePrefix-szel most ne foglalkozzunk, mert nem állítottuk be, viszont a tábla nevét (Table Name) töltsük ki azaz írjuk be, hogy: pages -  (hiszen ez volt a táblánk neve). Gii elvileg okosan megpróbálja kitalálni, hogy mi lesz (legyen) a Modell osztály elnevezése ... Majdnem jó is, én személy szerinte egyes számba szoktam tenni a Modell-jeimet (tehát pl: Page a Pages helyett). A többi értéket hagyhatjuk úgy ahogy van, és kattinthatunk az Előnézet (Preview) gombra.

Remélhetőleg egy új file név jelenik meg alul: models/Page.php. Ha erre a link-re kattintunk, akkor meggyőződhetünk róla, hogy igen, a mezők mind itt vannak és nyomhatunk egyet a Generate gombra. Ha jó Atyánk és a jogosultságok is úgy akarják, akkor a Page Modell osztályunk elészült a models/ mappa alatt.

Hát ennyi fért így a második részbe, elég sok mindent átvettünk, persze tudom, lehetne még ezt azt jobban részletezni, de a cikk célja inkább csak amolyan ismertetés féle. A következő részben használni fogjuk a Gii eszköz CRUD generáló finomságát, ami elkészíti majd nekünk a Kontroller és Nézet file-okat, az alap Create, Update, Read, Delete funkciókkal. Ja, és talán majd gépelni is fogunk egy kicsit ;)

Tuesday, July 12, 2011

Gittegylet meg a Yii - avagy Yiiki 2.0 (1. rész)

Ugyan ez egy új cikk, de nem teljesen. Talán a tavaly szeptemberben megjelent Yiiki avagy WIKI a'la Yii cikkben bemutatott rendszer 2.0-ás változatának lehetne tekinteni. 

Elég sok idő eltelt azóta és maga az alap keretrendszer is sokat változott, szerencsénkre. Még annyival szeretnénk kicsit megfűszerezni a fejlesztést, hogy bevonjuk a mostanában nagy népszerűségnek örvendő Git forráskezelőt. Vágjunk is bele.

Bevezetés

Magába az alapok installálásába nem fogunk belemenni, itt csak felsoroljuk mi mindent kell ismerni:

Objektum Orientált Programozás (PHP 5): A jelenleg stabil Yii 1.1.8-es verzió a PHP 5.1-en alapszik, tehát annak ismerete mindenképp szükséges. - http://hu.wikipedia.org/wiki/Objektumorientált_programozás

Adatbázis (SQL): A Yii, alapból sokféle adatbázis motort támogat. Az itteni példában én a SQLite-ot fogjuk használni, mert nem igényel különösebben bonyolult szerver oldali beállítást -  http://hu.wikipedia.org/wiki/SQL

MVC (Model-View-Controller) avagy Modell-Nézet-Vezérlő: A Yii az egy MVC-t szorgalmazó keretrendszer. Dióhéjban annyit jelent, hogy az alkalmazás jól elkülöníthető 3 részre. Az M vagy modell, ami az adatbázis jellegű lekérdezéseket végzi, a C vagy vezérlő ami kapcsolatot teremt és feldolgoz felhasználók által bevitt információt és végül a V vagy nézet, ami pedig magát a megjelenítést végzi. Ilyen többek között a Ruby On Rails rendszer is. - http://hu.wikipedia.org/wiki/MVC

Active Record - ami tulajdonképpen "megszűnteti" a függőséget a különböző adatbázisok között és az adatbázis táblákat objektumokként kezeli. Ez a gyakorlatban azt jelenti, hogy mondjuk fejlesztői környezetben használhatunk SQLite-ot élesben pedig MySQL-t vagy MsSQL-t stb.  - http://en.wikipedia.org/wiki/Active_record_pattern

- Git, forráskezelés - vagy verziókezelés alatt több verzióval rendelkező adatok kezelését értjük. Leggyakrabban a mérnöki tudományokban és a szoftverfejlesztésben használnak verziókezelő rendszereket fejlesztés alatt álló dokumentumok, tervek, forráskódok és egyéb olyan adatok verzióinak kezelésére, amelyeken több ember dolgozik egyidejűleg.

Apache, Nginx és egyéb web szerverek beállításába nem szeretnénk itt belemenni. A programot a következő konfigurációval készítettük:
- Ubuntu Linux (10.10)
- Apache 2.x
- SQLite 3
- PHP 5.3.x
- Yii 1.1.8

- Csomagoljuk ki a letöltött Yii-t a web szerverünk fő könyvtárába (pl. /var/www/yii ), a forráskód majd szintén a /var/www alá kerül (pl: /var/www/yiiki2).

Az is fontos, hogy a Yii rendszer a parancssorból is futtatható legyen! (PHP CLI)


A WEB alkalmazás létrehozása

Az alap alkalmazás létrehozása rendkívül egyszerű, csak adjuk ki a kovetkező utasítást (a web szerver root könyvtárából, ahol reméljük a maga a Yii rendszer is elhelyezkedit (pl /var/www).

./yii/framework/yiic webapp yiiki2





Ha minden jól sikerült, akkor a "Your application has been created successfully under /var/www/yiiki2" - szerű üzenet jelenik meg, ami röviden annyit jelent, hogy az alap program sikeresen létrehozva a megadott mappa alatt.

Azt már itt érdemes megjegyezni, hogy a programunk már ebben a fázisban működőképes. Ha megtekintjük a URL-t egy böngészőben (pl http://localhost vagy http://yiiki.peldaprogram.local) akkor egy (remélhetőleg) üdvözlő képernyő fogad bennünket.


Na itt a Git

Már rögtön az elején érdemes a munkánkat a forráskezelő alá tenni. Lépjünk be a yiiki2/ mappa alá és adjuk ki a következő parancsot.

$git init
Initialized empty Git repository in /var/www/yiiki2/.git/


Ez csak annyit jelent, hogy a Git sikeresen létrehozott egy üres (empty) forrástárat a megadott mappa alatt. Ha most megnézzük a könyvtárszerkezetet, akkor valami ilyesmit kell, hogy kapjunk. (rejtett file-okat is mutatva!)

$ll

drwxr-xr-x  8 imehesz imehesz 4096 2011-07-08 22:34 ./
drwxr-xr-x 42 imehesz imehesz 4096 2011-07-08 22:19 ../
drwxrwxrwx  2 imehesz imehesz 4096 2011-07-08 22:19 assets/
drwxr-xr-x  2 imehesz imehesz 4096 2011-07-08 22:19 css/
drwxr-xr-x  7 imehesz imehesz 4096 2011-07-08 22:34 .git/
drwxr-xr-x  2 imehesz imehesz 4096 2011-07-08 22:19 images/
-rw-r--r--  1 imehesz imehesz  478 2011-07-08 22:19 index.php
-rw-r--r--  1 imehesz imehesz  481 2011-07-08 22:19 index-test.php
drwxr-xr-x 14 imehesz imehesz 4096 2011-07-08 22:19 protected/
drwxr-xr-x  3 imehesz imehesz 4096 2011-07-08 22:19 themes/

Láthatjuk is, hogy a .git mappa ott figyel, amibe a Git program fogja tárolni a változtatásainkat.

Rutinos Yii-s mókusként tudjuk azt, hogy az assets/ a protected/runtime/ és a protected/data/ mappa alatt a Yii olyan dolgokat fog tárolni ami 99%-ban minden rendszeren más és más (pl. fejlesztői és éles környezet!), tehát érdemes lenne ezeket nem forráskezelő alá tenni, mert egyszerűen semmi értelme.

A Git erre egy nagyon elegáns megoldást kínál (illetve többet is), egyszerűen hozzunk létre egy file-t .gitignore néven (a yiiki2/ mappa alatt), és adjuk meg neki ezeket az útvonalakat. Így amikor a git ezekhez a mappákhoz ér, egyszerűen figyelmen kívűl hagyja őket. A gyakorlat azt diktálja, hogy még pár dolgot ne vegyünk forráskezelés alá, ilyenek például az adatbázis file-ok, vagy tömörített file-ok stb. Tehát a .gitignore file-unk valahogy így nézzen ki.

$less .gitignore

assets/*
protected/data/*
protected/runtime/*
*.zip
*.sqlite


Nos, eddig megvolnánk, de ha jól emlékszünk akkor a Git az elöbb azt mondta, hogy egy üres rendszert hozott létre. Ez igy is van. Az egyik legfontosabb Git parancs amit gyakran használni fogunk az a git status. Adjuk is ki:

$git status
# On branch master

#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
# .gitignore
# css/
# index-test.php
# index.php
# protected/
# themes/
nothing added to commit but untracked files present (use "git add" to track)


Amint láthatjuk, annyi történt, hogy a Git kilistázta, hogy mely file-ok változtak. Jelen esetben azonban még semmi nem változott, hiszen még semmit nem rendeltünk a forráskezelő alá. Ezt egyébként alul a Git szépen jelzi is, hiszen azt mondja, hogy nincs semmit a commit-hez hozzáadnunk, azonban vannak olyan file-ok amiket nem követ. Ja, és azt tanácsolja, hogy ezeket a git add utasítással adhatjuk a forráskezelő alá. Remek, pont ez kell nekünk. Adjuk is ki:


$git add .


A pont "." az azt jelenti, hogy MINDEN használható file-t vagy változást adjon hozzá a forráshoz. Miután kiadtuk a parancsot, szemmel láthatóan semmi nem történt, azonban a Git a háttérben szorgosan dolgozik. Ha most kiadjuk a git status -t, egyből észrevesszük, hogy igenis valami történt:



# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
# new file:   .gitignore
# new file:   css/bg.gif
# new file:   css/form.css
# new file:   css/ie.css
# new file:   css/main.css
# new file:   css/print.css
# new file:   css/screen.css
# new file:   index-test.php
# new file:   index.php
...


A lista elég hosszú, ide csak egy kis részletet illesztettünk be! A lényeg az, hogy ezek a file-ok készen állnak az un. commit-álásra, ami annyit tesz, hogy a módosításaink (jelen esetben új file-jaink) véglegesen a forrás részei lesznek. Magát a commit-álást pedig a -drrrrr ... dobpergés- git commit paranccsal hatjuk végre:


$git commit -m "itt a Yiiki2.0, elso commit-unk"


A -m (message) azaz üzenet, azt jelenti, hogy üzenetet fűzhetünk a commit-hez, aminek hiányát néhány programozó törzsek gyakran kéz- és/vagy fejvesztéssel büntetnek. Persze a képernyőn minden gyorsan leszalad, azért nézzük meg mi is történt:



[master (root-commit) 9e22a96] itt a Yiiki2.0, elso commit-unk
 Committer: Imre Mehesz <imehesz@imehesz-laptop.(none)>
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly:


    git config --global user.name "Your Name"
    git config --global user.email you@example.com


If the identity used for this commit is wrong, you can fix it with:


    git commit --amend --author='Your Name <you@example.com>'


 34 files changed, 1512 insertions(+), 0 deletions(-)
 create mode 100644 .gitignore
 create mode 100644 css/bg.gif
 create mode 100644 css/form.css
 create mode 100644 css/ie.css
 create mode 100644 css/main.css
...

Itt azt irta ki, hogy létrejött a commit, és a rendszer beállította a nevünket és az email címünket, de azért ellenőrizzük, hogy jó e. Még talán egy git parancsot érdemes itt megemlítenünk, a log -ot, ami az utolsó commit-okat listázza ki:

$git log
commit 9e22a96c0d94b58cb780eaa0d53fedd24df99242
Author: Imre Mehesz <imehesz@imehesz-laptop.(none)>
Date:   Fri Jul 8 23:24:51 2011 -0400

    itt a Yiiki2.0, elso commit-unk

Ebből a commit azonosítón kívül az is látszik, hogy pénteken este fél 12-kor nincs más dolgom, minthogy ilyeneket irogassak :)

A következő részben reméljük már talán valami kódot is sikerül majd írnunk!