Szántó Gábor Drupal oldala

Mostanában egyre többet dolgozok együtt másokkal. Hogy ne túrjuk szét egymás dolgait, ajánlott ugye verziókezelő használata, ami mi más lehetne drupal project esetén, mint a git.

A git alapokat megtanulni nem nehéz, ez a minimál workflow is mindössze néhány parancsot fog használni. Hogy miért minimál? Aki most dolgozik először gittel, az ilyen csudaságok, hogy branchek, submodule-k elég nehezen emészthető. Azért is minimál, mert ezeket minimum tudni kell, hogy csoportmunkában lehessen dolgozni.

Ez a folyamat feltételezi, hogy a közös munka egy fejlesztői szerveren zajlik, amihez mindenkinek van ssh hozzáférése. Mellette localhoston is van egy naprakész másolat a fájlrendszerről, és egy (legalább több-kevésbé) naprakész adatbázissal telepített drupal. Feltételez továbbá egy minimális parancssor használat tudást. Opcionális, bár erősen ajánlott: drush

Ami tilos: FTP, SFTP, rsync, vagy bármilyen egyéb eszközt használni a saját géped, és a fejlesztői szerver fájljainak szinkronizálására. Minden ilyen feladatot a git fog ellátni továbbiakban.

Akkor nézzünk szét először a fájlrendszer szintjén.
Megbeszéltük, hogy lesz a saját gépeden is egy fájlrendszer, ez a Te saját local repository-d, vagyis helyi tároló. Ezen Te szabadon barkácsolhatsz, ha valamivel úgy gondolod, kész vagy, kirakod a fejlesztői szerverre. (lásd később) Ez az a könyvtár, ahol a drupal telepítésed index.php-ja van.

Van ugye a fejlesztői szerveren is egy alap drupal telepítési mappa, ami a public_html, var/www, stb könyvtárban van, mindegy, a lényeg, hogy itt van az index.php. Ezt hívják gitül fejlesztői repository-nk, vagyis tárolónak.

Van egy harmadik is, amit bare repositorynak hívnak. Ez röviden arra való, hogy ő irányítja a fejlesztői szerveren és a fejlesztők saját gépei közötti fájlrendszerek szinkronizálását. Ez a fejlesztői szerveren egy nem publikus mappa, konkrétan drupal fájlrendszert sem tartalmaz, és igazából közvetlenül nem is fogsz vele találkozni. Ha én készítem el, akkor egyszerűen megadom a címét, egyszer beállítod, és vége, több dolgod nincs vele.

És itt jön a lényeg, hogy miért tilos bármilyen egyéb eszköz szinkronizálásra, sőt, közvetlenül a fejlesztői szerveren bármilyen fálj babrálása: Ha Te fogod, és FTP-vel felpakolsz valamit a fejlesztői szerverre, akkor ennek a "bare" repositorynak gőze sem lesz arról, hogy te felraktad, ergo a többi fejlesztő sem fog találkozni a módosításaiddal.
Szóval a párbeszéd a fejlesztői szerver és a bare repository között ebben a minimál folyamatban teljesen egyirányú, csak a bare repo rendezgetheti a fejlesztői szerver dolgait!

Viszont kétirányú a párbeszéd a saját helyi repod, és a bare repo között. Te a bare repoval fogod szinkronizálni a saját helyi fáljrendszeredet, a bare repo fogja átvinni ezt a fejlesztői szerverre. Ugyanerről a bare reporol fogják leszedni a többiek a Te módosításaidat.

Készen vannak a repok, van ssh kulcsod, megadtam a bare repo címét, akkor először szerezd meg, ahol épp a fejlesztés áll:

git clone ssh://[a bare repo címe]

Ezzel a saját helyi fáljrendszered egy alkönyvtárában (ez többnyire project_neve lesz, ha én csináltam a bare repot) létrejön a saját helyi repod.

Kezdjük el a munkát, letöltesz mondjuk egy új modult:

// a $ jelzi a promptot
$ drush dl cck

Ellenőrizd, hogy állunk a gitben:

$ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       sites/all/modules/cck
nothing added to commit but untracked files present (use "git add" to track)

Ahogy az üzenet is írja, itt bizony olyan dolgok vannak a fájlrendszerben, amiket a git még nem kezel, őket nem ismeri, mindjárt megmutatjuk a gitnek, de egyelőre töltsük le még mondjuk a views modult is.

$ drush dl views

Nézzük meg most a git statust:

: git status
# On branch 6.x
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       sites/all/modules/cck/
#       sites/all/modules/views/
nothing added to commit but untracked files present (use "git add" to track)

Most már a views is megjelent, ideje bemutatni a két ismeretlenünket a gitnek, erre több lehetőségünk is van, a lényeg és a parancs: git add
Ha a git add után beírjuk a statusban látott könyvtárat, pl sites/all/modules/cck/, akkor csak a cck könyvtárat adjuk hozzá egyelőre a repositoryhoz. Ez akkor hasznos, hogyha egyszerre több modult, sminket letöltesz, de dokumentálni szeretnéd külön-külön, vagy netán próbálgatsz localhoston egy modult, amit nem akarsz véglegesen bejegyezni a gitbe.

Ha a git add után .-ot (pont) írunk, akkor az összes a statusban felsorolt könyvtár be lesz jegyezve.
Tegyük most ezt:

$ git add .

Itt látszatra semmi nem történik, de ha nézel még egy git statust, bizony látható, hogy kilóméteres # new file:-al kezdődő sort kapsz. Ez jelenti azt, hogy most már a git ismeri ezeket a file-okat, rögzítette az indexébe, és "Changes to be committed", tehát rögzítésre váró változások találhatók a reponkban:

: git status
# On branch 6.x
# Your branch is ahead of 'origin/6.x' by 1 commit.
#
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   sites/all/modules/cck/CHANGELOG.txt

Már csak jóvá kell hagynunk, , rögzítenünk kell a változásokat, ez az ún. "commitolás". Commit során érvényesítjük a git statusban listázott, "Changes to be committed"-el jelölt módosításokat. Elég meglepően a git commit parancs való erre.

Ezt is hasonlóképpen használhatjuk, mint a git add-t. Ha git commit sites/all/modules/cck-val kezdjük a parancsot, akkor csak a cck modult commitoljuk. Itt viszont nem használhatunk .-ot az összes módosítás bejegyzésére, helyette bizonyos kapcsolók vannak, ezek közül a leggyakoribbak, amik kellenek:
-a : Ő jelenti azt, amit a git addnál a . Vagy "all", tehát minden változást commitolni akarunk
-m : Ezután adhatjuk meg a commit üzenetet "" között.

Ha már így szóba kerültek a commit üzenetek:
Minden commithoz tartozik egy üzenetet. Ezt tekinthetjük egyfajta fejlesztési naplónak is, ami eleinte fáj a fejlesztőnek, később nem tud nélküle élni. Egy rövid kitérővel szemléltetném a commit üzenet hasznát: Egyszer lett egy meredek hibaüzenet. Megkerestem, hogy mikortól csinálja ezt a hibát, a git naplóból visszanéztem, hogy mi is történt akkor, és hopp, meg is volt a bűnös. De még rengeteg példa van, főleg csoportmunkát tekintve, hogy miért jó a jó commit üzenet.

És akkor milyen a jó commit üzenet? (Ezekben semmi kötelező érvényű nincsen, csoporton belüli megegyezés kérdése, tapasztalataim szerint így érdemes használni)

1. Angol nyelvű (sosem tudni, mikor, hová kerül a munkád a későbbiekben)
2. Semleges személyű (Nem kell, hogy I change.. stb.. "Add module cck", 'aszt csókolom"
3. Azonosított, ha lehet mihez kötni: ez arra jó, hogyha egy megoldást pl egy drupal.org issue alapján készítettél el, ha patch is van benne, akkor egyenesen kötelező: pl "#[issue-nid]: #[comment-number] change.."
4. Ha nem dorgról, hanem máshonnan jött az instrukció, akkor lehetőleg a forrást is érdemes jelezni: "dhu#[nid]: #[comment-number] etc.."
5. Ez a jelölés különösen fontos lehet, hogyha issue-trackert is használunk, pl atriumot, mert a naplóból vissza lehet később keresni, hogy egy adott issue-hoz milyen módosításokat csináltunk"
6. És kerülendő: "Some other changes" Szóval azért tömören legyen benne, mi is történt igazából.

Na, ha már így tudjuk, mi az a commit, commitoljunk egyet, legyen most egyszerre az összes módosítás commit üzenettel:

: git commit -am "Add module cck and views"
[6.x a1c18d8] Add module cck and views
 575 files changed, 135851 insertions(+), 0 deletions(-)
 create mode 100644 sites/all/modules/cck/CHANGELOG.txt
 create mode 100644 sites/all/modules/cck/DEVELOPER.txt
...

Nézzük mi a helyzet git statussal ezek után:

: git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
nothing to commit (working directory clean)

Akkor értelmezzük ezt egy kicsit!
On branch master: A branchekbe most direct nem megyek bele. Ebben a minimál workflowban mindig a master nevű branchben dolgozunk. A branch egy fejlesztői ágat jelent, ami kvázi olyasmi, mint egy gyöngyfüzér, csak nem gyöngyöket, hanem commitokat fűzünk rájuk szépen, sorban a fejlesztés folyamatán.

nothing to commit (working directory clean): Ez azt jelenti, hogy a mi kis helyi reponk tiszta, nincs semmi új file, amit hozzá kell adni (git add), nincs semmi új módosítás, amit commitolni kell.

Your branch is ahead of 'origin/master' by 1 commit.: Hopi, ez elég baljósnak tűnik, és ezért is maradt utoljára. Ez a sor azt mondja nekünk, hogy az origin nevű távoli tárolón master branch-éhez képest egy committal előre járunk. (ez így nem a legpontosabb, ez most minimal git)

Fudenehézezt elmagyarázni, de megpróbálom:
Emlegettem az elején, hogy több reposítory van, ott van a bare, meg ez a bizonyos helyi repo, amihez most hozzáadtuk a views meg a cck modulokat. Mindegyik reponak saját branche van, amit most éppen masternek hívnak. Ez azt jelenti, hogy mindegyik reponak van egy saját gyöngyfüzére. Amikor mi commitolunk, akkor mi újabb gyöngyöt fűztünk a branchünkre, viszont a távoli repo branchén még az a gyöngy nincs ott.

Na ezt pótoljuk rögtön, de előtte nézzük, mi az az origin: Az origin nem más, mint a távoli bare reponk álneve. Próbáld ki, írd be, hogy git remote -v, és azt fogod látni, hogy ott van az "origin", mellette pedig a bare repo címe. Ezt az álnevet mindjárt arra fogjuk használni, hogy "megszólítsuk" a távoli reponkat.

Ezzel elérkeztünk oda, hogy szinkronizálunk, magyarul feltoljuk a fejlesztői szerverre, amit eddig ügyködtünk. Erre a git push parancs való. A legelső git push parancsunkat mindenképpen így adjuk ki:

git push -u origin master

Ezzel azt mondtuk, hogy a git tolja fel az origin álnevű távoli repoba a master nevű gyöngyfüzérünket, és a -u pedig azt jelenti, hogy mostantól a mi helyi reponk master nevű gyöngyfüzérét összekötöttük az origin nevű távoli repo master nevű branchével.
Tehát a továbbiakban a szinkronizáláshoz elég ennyit beírni:

git push

Szuper, már kint vannak a dolgaink. Azonban csoportban dolgozunk, tehát előfordulhat, hogy más is csinált már valamit. Ilyenkor a git push hibaüzenetet fog adni, és reklamál, hogy töltsük le, amit mások is felpakoltak.
Erre való a git pull parancs. Ha már git push-sal sikerült összekötnünk a saját reponkat a távolival, akkor elég ennyi: git pull
Ha még nem, akkor

git pull origin master

Magyarul: Git, rántsd le légyszi az origin álnevű távoli repo master gyöngyfüzérének a módosításait.

Nos, és ezzel gyakorlatilag felfegyvereztük magunkat a minimálisan szükséges git ismeretekkel, remélem, picit sikerült a git logikáját is megértetni.

Akkor végére néhány okosság:

1. Napi 1 commit nem commit. Próbálj meg feladatorientáltan commitolni. Ha pl css-ben megformáztad a commenteket, akkor commit, ha valami fontos hibát javítottál, megint commit. (Lásd a post elejére beszúrt képet)
2. Próbáld meg a promptod gitbarátra hozni: http://www.google.hu/search?aq=f&sourceid=chrome&client=ubuntu&channel=c... Itt rengeteg olyan PS_1 beállítást találsz, amivel már parancssorból látod, hogy hogyan állsz a local repodban.
3. Ha velem dolgozol, általában találsz a gyökérkönyvtárban egy .gitignore nevű fájlt. Ebben ilyenek vannak, hogy sites/default/settings.php, .htaccess, szóval azokat a fileokat, amiket a git automatikusan nem vesz figyelembe. Ha valami olyasmi van a könyvtáradban, ami szemét (pl egy ide projectbeállításai), akkor ebbe a .gitignore nevű fileba pakold bele, és akkor nem kerül fel a szerverre.
4. Guglizz utána: git alias Nagyban megkönnyíti a munkát, később én is írok majd róla.
5. Próbáld ki időnként ezt: git diff, megmutatja, hogy milyen különbségek nincsenek még elcommitolva, és szokod a patch látványát is.

Hu, remélem, nem hagytam ki semmit, és ez alapján sikerül elindulni.
Ha kérdés van, noszarajt, sztem van anonim comment is.