Minimál git workflow drupal fejlesztéshez

  • GeSHi library error: sites/all/modules/geshifilter/geshi is not a directory.
  • GeSHi library error: sites/all/modules/geshifilter/geshi is not a directory.
  • GeSHi library error: sites/all/modules/geshifilter/geshi is not a directory.
  • GeSHi library error: sites/all/modules/geshifilter/geshi is not a directory.
  • GeSHi library error: sites/all/modules/geshifilter/geshi is not a directory.
  • GeSHi library error: sites/all/modules/geshifilter/geshi is not a directory.
  • GeSHi library error: sites/all/modules/geshifilter/geshi is not a directory.
  • GeSHi library error: sites/all/modules/geshifilter/geshi is not a directory.
  • The spam filter installed on this site is currently unavailable. Per site policy, we are unable to accept new submissions until that problem is resolved. Please try resubmitting the form in a couple of minutes.
Kategória: 
Leírás
Minimál git workflow drupal fejlesztéshez

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:

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

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:
[geshifilter-code] // a $ jelzi a promptot $ drush dl cck [/geshifilter-code]

Ellenőrizd, hogy állunk a gitben:
[geshifilter-code] $ 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) [/geshifilter-code]

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.

[geshifilter-code] $ drush dl views [/geshifilter-code]

Nézzük meg most a git statust:

[geshifilter-code] : 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) [/geshifilter-code]

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:

[geshifilter-code] $ git add . [/geshifilter-code]

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:

[geshifilter-code] : 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 [/geshifilter-code]

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 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:

[geshifilter-code] : 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 ... [/geshifilter-code]

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

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

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:

[geshifilter-code] git push -u origin master [/geshifilter-code]

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:

[geshifilter-code] git push [/geshifilter-code]

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

[geshifilter-code] git pull origin master [/geshifilter-code]

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.

Hozzászólások

Thanks, this website is

Thanks, this website is really useful.

Amazing website you've here.

Amazing website you've here.

You've probably the greatest

You've probably the greatest sites.

Incredible, this is a helpful

Incredible, this is a helpful web page.

Amazing webpage you have

Amazing webpage you have going here.

Thanks very useful. Will

Thanks very useful. Will certainly share site with my buddies.

I benefit from browsing your

I benefit from browsing your website. Many thanks!

Many thanks for sharing this

Many thanks for sharing this excellent web page.

Passion the site-- really

Passion the site-- really user friendly and lots to see!

Thanks a ton for sharing this

Thanks a ton for sharing this neat site.

Hozzászólás

A mező tartalma nem nyilvános.
  • Internal paths in double quotes, written as "internal:node/99", for example, are replaced with the appropriate absolute URL or relative path.
  • Engedélyezett HTML elemek: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <del> <img>
  • A webcímek és email címek automatikusan linkekké alakulnak.
  • A sorokat és bekezdéseket a rendszer automatikusan felismeri.
  • Engedélyezett HTML elemek: <a> <blockquote> <br> <cite> <code> <dd> <del> <div> <dl> <dt> <em> <li> <ol> <p> <span> <strong> <ul>
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>, <bash>, <c>, <cpp>, <drupal5>, <drupal6>, <java>, <javascript>, <mysql>, <php>, <python>, <ruby>, <sql>. The supported tag styles are: <foo>, [foo].
  • Minden email cím át lesz alakítva ember által olvasható módon, vagy (ha a JavaScript engedélyezett) ki lesz cserélve kattintható, de biztonságos hivatkozásra.