Git hub létrehozása Drupal oldal fejlesztéséhez - vitapost

Kategória: 
Leírás

Ez post tipikusan olyan dolgokat tárgyal, amik nincsenek kőbe vésve. NeverGone szerint már maga az, hogy "hub" zavaró a github.com miatt. Ez a rész szerintem ok, hiszen kvázi hidat hozunk létre sok sok developer és a public project között.

Úgyhogy vitassuk meg, hátha kisül belőle valami okosság!

A sztori a következő: Lelkesen belevágtam a git-be néhány héttel ezelőtt. Küzdöttünk rendesen, ilyen workflow, olyan branchelés, így submodule, rengeteg git reset --hard. Szóval szépen összemelegedtünk, gyűltek a linkek del.icio.us-ban, mentek a commitok, egészen követhetővé vált a fejlesztés, és már kétszer is volt, hogy egy bugfixnél a git log segített.

Szóval a git jó. De egy benga állat, ezerfejű szörny, és amikor azt hiszed, hogy már eléggé megszelidítetted, dolgozik, mint egy kezesbárány, megfordul, és a fejedre szarik.

Na valami ilyesmi volt most velem is. Nagyon szépen eldolgozgattam otthon, meg a githubról és a git.drupal.orgról oda-vissza mentek a dolgok, ahogy kell. Aztán egyszer csak ki kellett volna pakolni, ami eddig volt. Az emberfia ugye nem azért használ gitet, hogy utána rsyncel tologassa repóstól commitostól a dolgait, úgyhogy eljött az idő, hogy végre a közös pushnak pull legyen a vége.

Na és akkor itt érdemes tisztázni valamit: Alapdolog, ám sokáig nem volt nyilvánvaló. Olyat sosem csinálunk, hogy egy munkakönyvtárba tolunk fel (git push) dolgokat. Munkakönyvtár az, ahol a file-ok, mappák vannak. Gitben létezik egy olyan csoda, hogy bare repository. Ebben nincs egy deka munkafile sem, csak a githez kapcsolódó dolgokat, commitokat, brancheket, objektumokat tárolja. Ennek a bare repositorynak a feladata az ide-oda szinkronizálgatás.
Edit: Én lépten nyomon azzal találkoztam, hogy nem jó non-bare repositoryba pusholni, NeverGone szerint lehet ez indokolt, illetve praktikus, illetve meg is van rá a megfelelő kezelés.

Szóval röviden néhány fogalom:

Repository (általában): Tároló. Ez egy könyvtár, amiben van maga a drupal, a teljes kódbázis, modulok, képek pucérnőkről, ésatöbbi. A mezei drupal könyvtártól az különbözteti meg, hogy van benne egy .git könyvtár, és ebbe kerül minden varázslat, amit a gittel követünk el.

Bare repository: Ez maga a hub. Ehhez kapcsolódik a product site, a development site, és az összes developermaki (akik szeretik a banánt), akik a kódot gyúrják.

Local repository: Ez az én, te, stb, géped itt az orrod előtt. Letöltöd a drupalt, modulokat, dolgozol, teszel, és azt azt mondod, hogy git push, és huss, már kint is vannak az ügyködéseid. (ez az, ami nem olyan egyszerű)

Product repository: Ööö.. Hát ez sem így fog elterjedni a magyar nyelvben, de a lényeg a következő, hogyha beütöd a böngészőbe, hogy http://enkezemmunkaja.hu, vagy http://dev.ketkezemunkaja.hu, akkor te az ebben a repositoryban lévő kódbázis alapján látod a dolgokat.

Branch: Fejlesztői ág, ezt tekinthetjük hivatalosnak is magyarul. De ez így elég absztrakt, szóval nézzük meg egy kicsit közelebbről. Elkezdünk egy drupal munkát amiből előbb utóbb éles oldal lesz. De ahhoz fejleszteni kell az oldalt.
Sasszemmel már a tipográfiából kiszúrhattad, hogy meg is van a két branchünk, nevezzük ezeket szépen magyarul masternek, és develnek.
Ahogy töltögeted a modulokat, tekergeted a cckt, views, csinálod a sminket, addig csak fejlesztesz, gitül szólva a devel branchben dolgozol. Amint azt mondod, hogy kösz szépen, ez már itt elég jó, mehet élesbe, azt mondod a devel branchnek, hogy légy master, vagyis amit eddig csináltál a develben, átkerül a masterbe, ezt a folyamatot gitül mergenek hívják.
Ezután visszaválthatsz develbe, kipróbálgathatsz új dolgokat, és ha netán valami szuperjót sikerült összehozni, akkor a devel ágadat megint belemergeled a masterbe, tehát élesíted a fejlesztésedet.

És egy elméleti ábra, amit innen szedtem:

Ahogy elnézem, ez lesz az a post, ahol a bevezető hosszabb, mint a lényeg..

Merthogy ez a párbeszéd nem is olyan egyszerű.

Először kell hozzá ssh hozzáférés a szerveren, és nem árt valami emberi oprendszer a saját gépeden, ebbe a kategóriába a W betűvel kezdődő és indowsra végződő oprendszerek nem tartoznak bele.
Edit: Nem feltétlenül kell hozzá ssh hozzáférés, legalábbis a git parancsok használatához. Viszont a beállításokhoz, inicializáláshoz nem árt, ha van. A gitnek van saját protokollja, ami elmegy HTTP-vel

Tegyük fel, hogy a sajátgépeden itt fogunk dolgozni:
~/public_html/munka - ebben kerül a drupal telepítés.

A szerveren a van egy dev, és egy éles könyvtár

~/dev.munka/public_html
~/live.munka/public_html

Most a leszedjük, branchelünk, stb dologba nem mennék bele: http://drupal.hu/tippek/gitreferenciasitebuild itt szépen van írva minden. A mi szempontunkból az a lényeg, hogy van egy branch, a devel, amiben gyűjtünk mindent, és egy master, ami az éles lesz.

Akkor kezdjük a szerveren.

Csináljunk könyvtárat a hubnak:

cd ~
mkdir repos //ide fogjuk gyűjteni az összes hub könyvtárat
mkdir repos/munka.git //ez a mostani munkánk hubja lesz
cd repos/munka.git
git --bare init //ezzel meg azt mondjuk meg a gitnek, hogy ez a repo bare lesz

Na drupalosok öröm van, mert kéremszépen gitéknél is hookolhatunk kedvünkre! Gitnél a hookat kvázi bash szkriptek jelentik. Nézzünk be a .git/hooks könyvtárba. Ilyenek vannak pl, hogy post-commit.sample. Semmi más dolgunk nincs csak átnevezni a hookot post-commit -ra, és beleírni a bash szkriptünket.

Bare reponál az a célunk, hogyha valamelyik developermaki kommitál, akkor az kerüljön ki szépen a devel, vagy a master oldalra.

Ehhez a post-update hookot kell megvalósítanunk a repos/munka.git/.git/hooks könyvtárban, és hogy zsernonek is kicsit hadd repdessen a szíve, mert ilyeneket meg tőle tanultam, legyen az, hogy

vim post-update

És beléje a kód, ami iszonyat randa, de a minimál bash tudásomból kb ennyire futotta, szóval patches are welcome! :)

branch=$(git symbolic-ref HEAD)
if [ "$branch" = "refs/heads/devel" ]
then
  cd $HOME/dev.munka/public_html || exit
  unset GIT_DIR
  git pull hub devel
else 
  cd $HOME/munka/public_html || exit
  unset GIT_DIR
  git pull hub master
fi
 
exec git-update-server-info




És jöjjen egy update, mert viharba kerültem: Szóval a bare repoban a git symbolic-ref HEAD a repoban aktuális branchet mutatja, nem pedig azt, ahonnan a push jött. Egy tesztkörnyezetben próbáltam a szinkronizálást, és arra a következtetésre jutottam, hogy feltételezve, hogy minden push után szinkronizálás történik, nem lehet gond abból, ha a push branchétől függetlenül mindkét munkakönyvtár frissítve lesz. Max egy Already up to date-et kapunk a másik branchtól.

Tehát ezzel tudunk push branchtól függetlenül frissíteni a repokat, ami nagyon nem tetszik a nyilvánvalóan felesleges pull miatt, szóval jó lenne valami feldolgozható feltételt találni.

cd $HOME/dev.munka/public_html
unset GIT_DIR
git pull hub devel
cd $HOME/munka/public_html
git pull hub master
exec git-update-server-info




Most állítsuk irányba a fejlesztői oldalunkat:
Ha még tök üres a könyvtár, akkor:

cd ~/dev.munka/public_html
git init
touch index.php
git add .
git commit -am "Initial commit"
git checkout -b devel //létrehozzuk a devel branchet és át is lépünk bele
git branch -d master // töröljük az eredeti master branchet, mert ide nem kell

Ha már dolgoztunk gittel a szerveren, és ugyanúgy össze-vissza, mint én, akkor már van kész repositoryk. Ekkoris törölhetjük a felesleges brancheket, valahogy tisztább, szárazabb, boldogabb érzés.

Folyt:

git remote add hub ~/repos/munka.git //hozzáadjuk a hubot
git remote show hub // nézzük meg, nem csesztünk-e el valamit
* remote hub
  URL: /home/userneved/repos/munka.git
git push hub devel // és szépen feltoljuk, amit eddig műveltünk

Mivel most a dev könyvtárban vagyunk, lehet olyan igényünk, hogyha valamit közvetlenül a szerveren commitolunk, az kerüljön fel a hub-ra (sosem lehet tudni..) Erre a már emlegetett post-commit hookot használjuk, és legyen az benne, hogy:

#!/bin/sh
git push hub

Nos, a szerveren nagyjából készen vagyunk, még dettó ugyanezt meg kell csinálni az éles oldal könyvtárában, csak természetesen odafigyelve a branchekre, hogy devel helyett mastert használjunk, és még véletlenül se a mastert töröljük.

Akkor vissza sajátgépre. (Nekem meg vissza a post elejére, mert pl már gőzöm sincs, hogy hoztunk-e létre repot, stb..)
Aham, meg is van, szóval játszuk azt, hogy van már master, és devel reponk itthon.

Ehhez először tudatnunk kell a gittel, hogy nekünk van ám más helyen is reponk, nem csak itthon.

git remote add munka ssh://userneved@teoldalad.hu/home/userneved/repos/munka.git
git fetch munka // Ezzel kérdezzük le, hogy miújság a szerveren, milyen branchek vannak
git branch -r // ezzel megnézzük, milyen távoli repokat kaptunk az előbbi git fetch-chel

Elvileg ilyeneket kéne látnunk:

remotes/munka/devel
remotes/munka/master

Akkor passzítsuk őket:

git branch --set-upstream devel remotes/munka/devel
git branch --set-upstream master remotes/munka/master

És ezzel készen vagyunk. Mehet a git pull, és a git push, attól függően, hogy melyik branchben vagyunk, oda fog kerülni az oldalon.

Na és akkor a warningok:

Nem győzném felsorolni, hogy milyen forrásokból, honnan szedtem ezeket össze. Az egész gitesdi még nem az stabilan kiforrott dolog drupal körökben, jómagam azért követek pár kezdeményezést.

Jelenleg egy orbitális öntökönszúrást gyógyítottam ezzel a módszerrel, élesben egyelőre csak devel branchet szinkronizálok, azzal szépen működik. A bash szkripteket localhoston kipróbáltam, master szinkronizációt viszont kvázi élesben még nem használok, ez a project nincs még abban a stádiumban.

Szóval csak óvatosan! És akár kommentelni is lehet.

Igazából itt dobnám be azt, hogy akár ki is tárgyalhatnánk ezt a témát keményen. Ahogy már említettem, patches are welcome, a saját tapasztalatokból össze is hozhatnánk valami értélhetőt!

Az utólagos editekért thx NeverGonenak (és majd jönnek sorra a többiek)!


Hozzászólások

Köszönöm, a postod sokat

Köszönöm, a postod sokat segített :)

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.
Type the characters you see in this picture. (verify using audio)
Type the characters you see in the picture above; if you can't read them, submit the form and a new image will be generated. Not case sensitive.