Ugrás a fő tartalomra

SVN / GIT / GITHUB alapok 1

Definíciók

Az SVN-ben definiált fogalmak és műveletek móricka-definíciója:

Fogalmak

  • repository - A központi, szerver oldali, verziózott fájl-tároló, ebből csak egy példány van. Egy fál, vagy könyvtár több eltérő verzióját, azonosítható módon tartalmazza. Az alábbiakban a REP vagy URL rövidítést is használjuk a repository jelölésére.
  • verzió - A repositoryban tárolt fájlok egy adott pillanat beli állapota, egyfajta sorszámozott snapshot.
  • HEAD - A repositoryban tárolt legfrisebb verziószám jelölésére használatos elnevezés. Általában ha nem adunk meg verziószámot, az alapértelmezett a HEAD lesz.
  • branch - „Fejlesztési ág”, „ág”. A repository azon része, alkönyvtára, mely egyedi fejlesztéseket, kísérleti ágakat, támogatott disztribúciókat tartalmazza. Jellemzően a /branches könyvtárban kap helyet minden branch.
  • stable branch - „Stabil ág”. Egy olyan, hosszabb távú támogatást élvező, jellemzően verziószámmal ellátott branch, melyet a fejlesztők „stabil” verziónak jelöltek meg. Csak a kritikus frissítéseket szokás belevezetni. Célszerűen csak egy ilyen van. Elterjedt megoldás, hogy a trunk látja el ezt a feladatkört, de elképzelhető más gyakorlat is.
  • development branch - „Fejlesztői ág”. Értelemszerűen egy olyan branch, melyben fejlesztői, kísérleti munka folyik. Jellemzően több ilyen lehet.
  • trunk - „Kódtörzs”, „törzs”. A repository azon része, alkönyvtára, mely a szoftver fő fejlesztési irányát, kódbázisát képviseli. Jellemzően a /trunk alkönyvtárban kap helyet. A trunk-ben jellemzően minden fájl csak egyszer szerepel. Általában a trunk is egy branch.
  • tag - „Jelölés”, „jel”, „címke”. Egy branch egy adott verziójának megkülönböztető céllal készített másolata. Jellemzően a /tags könyvtárban kap helyet. Elterjedt megoldás a stable branch fő verzióit tag-ekkel megjelölni, úgy, hogy a tag neve az adott stable branch verziószámát is tartalmazza. A tag gyakorlatilag egy soha meg nem változó, „statikus” branch.
  • working copy - „Munkamásolat”, „munkapéldány”. Egy fejlesztő által használt, a repository egy adott verziójából készült részleges, vagy teljes másolat, jellemzően egy branch vagy tag alkönyvtárának másolata. A másolatban .SVN nevű könyvtárakban meta-információk tárolódnak, melyeket kézzel szerkeszteni, másolni nem szabad. Jellemzően fejlesztői célokat szolgál. Általában a working copy csak egy branch adatait tartalmazza, nem szokás az egész repository-t working copyként használni. Az alábbiakban a WC rövidítést is használjuk a working copy jelölésére.
  • export - A repository egy adott verziójából készült részleges, vagy teljes másolat, egy branch vagy tag másolata. Ezt a fajta másolatot nem köti semmi a repository-hoz, így a rajta végrehajtott módosítások visszajuttatására már nincs lehetőség. Jellemzően disztribúciós célokat szolgál, ezért jellemzően a stable branch másolataként tekinthetünk rá.

Alapvető halmazműveletek

  • commit - A working copyban végrehajtott változtatások (vagy részhalmazuk) alapján új repository verzió létrehozása, a változtatások feltöltése. Fontos lépés a commithoz tartozó megjegyzési mező kitöltése, mely naplóbejegyzésként funkcionál a repository-ban. Ha több fejlesztő párhuzamosan ugyanazokat a fájlokat, ugyanazokon a helyeken módosítja a working copy-ban, az időrendben későbbi commit sikertelen lesz és az azt kezdeményező fejlesztő feladata a módosítási ütközések („conflict”) feloldása.
  • update - A working copy frissítése a repository, vagy branch valamely újabb verziója alapján, a lokális változásokat megőrizve. A commit-hoz hasonlóan itt is ütközések léphetnek fel, melyeket szintén fel kell oldania az update-et kezdeményező felhasználónak.
  • revert - A working copy-n (vagy részhalmazán) végrehajtott változtatások eldobása.
  • resolve - A commit vagy update által felderített ütközések feloldása. Alapvetően minden ütközés manuális beavatkozást igényel. A magasszintű eszközök általában fejlett támogatást nyújtanak hozzá.

Alapvető fájlműveletek

  • copy - Univerzális fájlművelet, fájlok vagy alkönyvtárak másolására használható különböző források és célok között, az SVN meta-információk megőrzésével. Létezik WC → REP, WC → WC, REP → WC és REP → REP irányú copy.
  • move, rename - Univerzális fájlművelet, a copy-hoz hasonlóan működik, de nem másolja, hanem mozgatja a fájlokat, alkönyvtárakat a megadott forrásból a célba.
  • delete - Univerzális fájlművelet. A copy és a move/rename műveletekhez hasonlóan működik, fájlok és könyvtárak törlésére használatos a working copy vagy a repository oldalán.
  • add - A working copy területén létrehozott új fájlok és könyvtárak hozzáadása a verziókövető-rendszerhez. A következő commit már ezeket is érinteni fogja. Értelemszerűen azon új fájlok és könyvtárak, melyekhez nem hozzuk létre az SVN meta-információkat az add művelettel, nem kerülnek bele a commitba. Sok SVN frontend (pl.: TortoiseSVN) a commit során automatikusan felajánlja az add lehetőségét, ezzel azonban óvatosan kell bánnunk, mert nem célszerű pl. a szövegszerkesztő által létrehozott átmeneti álományok verziókövetőbe történő betöltése.

Egyéb, ritkábban használatos elemi műveletek

  • checkout - A working copy kezdeti kimásolása a repository-ból. Jellemzően a fejlesztői munka megkezdése előtt, egyszer kell végrehajtani.
  • import - Még nem verziókezelés alatt álló fájlok és könyvtárak kezdeti betöltése a repository-ba.
  • export - Export készítése (lásd: fogalmak).
  • switch - Working copy váltása. Eredménye gyakorlatilag azonos a working copy-ban található adatok kidobásával és egy másik branch checkout-olásával. Biztonsági ellenőrzéseket végez, hogy nem commitolt módosítások ne veszhessenek el és nem végez fölösleges fájlműveleteket. A repository URL változásának követésére is használható.
  • lock - A repository egy részéhez (alkönyvtárához, fájljához) tartozó terület zárolása. A lock megnehezíti a commitot a többi fejlesztő számára, de nem akadályozza azt meg (van „forced” commit és „forced” lock). Jellemzően nagyobb átalakítások során használatos, nem a mindennapi munka eszköze.
  • unlock - A lock inverz művelete, a zárolás feloldása.
  • merge - Az egyik legösszetettebb feladatot ellátó SVN művelet. Általános esetben a megadott két branch megadott két verziója közti különbségeket (ún. „changeset”) kigyűjti, majd alkalmazza ezeket egy working copyra. Ha a megadott verziókat M és N betűkkel, a különböző helyeket pedig 1, 2 és 3 számokkal jelöljük, a következő esetek valósíthatók meg: (REP1@M - REP2@N) → WC, (WC1@M - WC2@N) → WC3, (REP@M-N) → WC, (WC1@M-N) → WC2.

Példák

Az alábbiakban a fejlett SVN használat, főként branching és tagging, jobb megértéséhez mutatunk pár gyakorlati példát. A példákban a műveletek általános leírásán kívül az SVN parancs parancssori használatát is szemléltetjük. A magasabb szintű SVN frontendek esetében az egyes műveletekhez külön támogatást is találhatunk, ám ezek is a szemléltetett primitív műveletekből épülnek fel.
A példákban használt repository (standard) alapfelépítése a következő:
/calc/tags
/calc/branches
/calc/trunk

Branch (vagy tag) létrehozása

A branch létrehozását mindig a repository oldalán kell kezdeményeznünk. Erre a feladatra a copy művelet a megfelelő. Jellemzően a trunk másolatát készítjük el. Ugyanez az eljárás használható tag létrehozására is.
Például, ha az új branch neve „my-calc-branch”, az alábbi parancsot kapjuk:
$ svn copy http://svn.example.com/repos/calc/trunk \
           http://svn.example.com/repos/calc/branches/my-calc-branch

Branch törlése

Ha egy branch-ra már nincs szükségünk, nyugodtan törölhetjük, hisz a verziókövető rendszerben megmarad. A working copy egyszerűen törölhető, a repository oldalt pedig a delete művelettel törölhetjük.
Például az alábbi parancssort kapjuk:
$ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \
             -m "Removing obsolete branch of calc project."

Branch visszaállítása

A branch törlése, ahogy ezt említettük, nem jelenti a repository-ból való eltávolítását, csupán azt, hogy nem szerepel többé a HEAD verzióban. Egy megadott verzióban (pl.: 374) még létező branch visszaállítását a copy művelettel végezhetjük.
$ svn copy -r 374 http://svn.example.com/repos/calc/branches/my-calc-branch \
                  http://svn.example.com/repos/calc/branches/my-calc-branch

Branch visszaolvasztása a trunk-be


A lépések a következők:
  • Checkoutoljuk és/vagy updateljük a trunk-öt. A példánkban a WC a calc/trunk könyvtárban van.
  • A kiválasztott branch összes módosítását merge művelettel beolvasztjuk a working copy-ba. Jelen példánkban feltételezzük, hogy a branch létrehozásának verziószáma 341, az aktuális verzió pedig általában a HEAD.
  • Státuszt kérünk, feloldjuk az esetleges ütközéseket, stb.
  • Commitoljuk a módosított trunk working copy-t.
$ cd calc/trunk
$ svn update
At revision 405.

$ svn merge -r 341:HEAD http://svn.example.com/repos/calc/branches/my-calc-branch
U   integer.c
U   button.c
U   Makefile

$ svn status
M   integer.c
M   button.c
M   Makefile

# ...examine the diffs, compile, test, etc...

$ svn commit -m "Merged my-calc-branch changes r341:405 into the trunk."
Sending        integer.c
Sending        button.c
Sending        Makefile
Transmitting file data ...
Committed revision 406.




 Git használata /  Bevezetés 

A Git egy nyílt forráskódú, elosztott verziókezelő szoftver, mely a sebességre helyezi a hangsúlyt. A fejlesztők a saját gépükön nem csak a repository-ban (tárolóban) lévő legfrissebb állapotát tárolják, hanem az egész repot.

A verziókezelői tevékenységek végrehajtása nagyon gyorsan történik, mely a Git erősségét is adja. A központi szerverrel történő hálózati kommunikáció helyett a lokális számítógépen hajtódnak végre a parancsok, így a fejlesztés offline megy végbe a workflow megváltoztatása nélkül.

Mivel minden egyes fejlesztő lényegében teljes biztonsági másolattal rendelkezik az egész projektről, ezért a szerver meghibásodásának, a tároló megsérülésének vagy bármilyen bekövetkező adatvesztésnek a kockázata sokkal kisebb, mint a központosított rendszerek által támasztott pont-hozzáférés esetében.

A Git repository minden egyes példánya – akár local, akár remote – rendelkezik a projekt teljes történetével, így egy teljes, elszigetelt fejlesztői környezetet biztosít minden fejlesztő számára, hogy szabadon kísérletezzenek új funkciók fejlesztésével mindaddig, amíg egy tiszta, publikálható verziót nem képesek előállítani.


 Fogalmak 

A Git hasonló egy hash-fához, azonban az egyes csomópontokon és leveleken hozzáadott adatokkal rendelkezik.
A Git célja az adott projekt menedzselése, ill. az adatok változásának nyomon követése. Ezen információk adatstruktúrákban történő tárolását repository-nak, röviden repo-nak, avagy lokális adatbázisnak nevezik.
A working directory, working copy vagy history az adott projektről, gyökérkönyvtáráról – amelyben a fájlok, forráskódok és mappák találhatóak – egy változatot, verziót, állapotot tartalmaz.


Snapshot egy adott pillanatban, időpontban a könyvtárak, fájlok aktuális állapotát, tartalmát, verzióját jelenti. A pillanatkép úgy képzelhető el, mint egy fotó a teljes kódról.

Staged, cached jelzővel illetik azokat a fájlokat, amelyek módosítva lettek és az állapotukról, verziójukról, tartalmukról snapshot készült.

Commit-nak nevezik azt a folyamatot, amely során a Git a megjelölt és a staging areaban lévő fájlokról készült snapshot-okat a .git könyvtárában, azaz a lokális adatbázisában tárolja el biztonságosan, és egy SHA-1 hash kódot generál, amellyel a snapshot-okra hivatkozik.

A Git lehetővé teszi, hogy a módosult fájlok közül egy csokorban csak azok kerüljenek eltárolásra az adatbázisában, amelyeket a fejlesztők szándékoznak. Ezért a working directory és a lokális adatbázis közé egy harmadik, index, cache, staging area szinonima nevekkel illetett átmeneti területet, pontosabban egy egyszerű fájlt alakítottak ki, amelyben információk szerepelnek arról, hogy a következő commit során mely snapshotok legyenek eltárolva.

Röviden az a staging area a fájlrendszernek a commit-ra jelölt elemei snapshot-jait tartalmazza.

A working directory-t tisztának nevezik, ha a fájlokon végzett összes módosítás el van mentve a lokális Git adatbázisba, a repo-ba. Ilyenkor az utolsó commit óta nem történt változtatás az adatokon.

Branch-nek nevezik azon commit-ok összességét, melyek egy közös ágazatba lettek rendezve, és egy közös ős commit-ból erednek lineárisan egymás után fűzve.

HEAD a legutolsó commit-ra való hivatkozás az aktuális branch-ben.
A kiadott Git parancsok minden esetben az aktuális branch-re vonatkoznak. Mindig létezik egy aktív, kiválasztott aktuális branch.

 Fájlok állapotai 

A Git untracked jelzővel illeti azokat a fájlokat, mappákat, amelyekről még egyetlen snapshot sem készült (nem szerepelnek a staging area-ban, ill. nem része a lokális adatabázisnak), tehát nem követi nyomon a rajtuk végzett módosításokat.
                                         
 

Tracked megjelöléssel szerepelnek azok az adatok, amelyek tartalmának változását a Git nyomon követi.

A tracked fájloknak 3 további állapotuk lehetséges: 

 - modified: a fájl módosult a legutóbbi commit óta, de az aktuális verziója még nincs a staging area-ban (nem készült róla snapshot), ill. a következő commitnak nem lesz része
 - unmodified: a fájl nem módosult a legutóbbi commit óta (tiszta)
 - staged, cached: a fájl módosult a legutóbbi commit óta és már snapshot is készült róla (a staging area része), a következő commit során el lesz tárolva az adatbázisban



GIT használat minta




Először is megmondjuk a Git-nek, kik is vagyunk mink:

$ git config --global user.name "Saját Nevünk"
$ git config --global user.email "saját@email.címünk"

Ezután Git adatbázist szeretnénk. Git adatbázis mindig egy teljes könyvtárhoz (alkönyvtárakkal együtt) készül. Adatbázisunk kétféleképp lehet: szerzünk egyet, vagy csinálunk egyet a saját könyvtárunkról.

Git adatbázist csinálni egyszerű: a kívánt könyvtárban azt mondjuk, hogy

$ git init

Ez létrehozza a könyvtárunkban a .git/ adatbázist.

Szerezni is egyszerű. Mi egy Szerver nevű gépéről ssh-n keresztül fogjuk hozni-vinni a cuccainkat, ezért ezt írom le (de megjegyzésképp a Git működik http-n, rsync-en, és egy saját git protokollján keresztül is). Feltesszük, hogy ezen a szerveren van már egy proba nevű adatbázis (ssh git szerver leírása lejjebb). Amikor először szedjük le a proba nevű adatbázist,

git clone projfelh@valami.szerver.hu:proba

Ez létrehozza a proba nevű könyvtárat a proba project filejaival, és egy .git könyvtárral, ami a proba teljes adatbázisát tartalmazza. (Ékezetet semilyen filenévben és felhasználónévben sem érdemes használni. :-) )

Van tehát egy könyvtárunk egy git adatbázissal. Ebben a könyvtárban módosítunk valamit, elmentjük ahogy szoktuk a munkánkat, viszont ettől még nem kerül be a Git adatbázisába. Ehhez először ki kell jelölnünk, hogy mely fileokat ajánljuk a Git figyelmébe:

$ git add file1 file2 file3

vagy
$ git add .

ha minden file-t a figyelmébe ajánlunk.

Ezután azt kell mondani, hogy

$ git commit

ekkor egy editort nyit meg, amibe pár szóval érdemes leírni mit dolgoztunk. Humanitárius okokból itt ne használjunk ékezeteket. :-) (Ha nem tetszik az editor amit a Git használ, hanem inkább emacs-et használnánk, akkor

$ git config --global core.editor emacs

) Ha kész, akkor az editor bezárása után a változás el lett mentve a Git helyi adatbázisába. (Megjegyzés: meg lehet mondani a Git-nek, hogy bizonyos fileok engem sosem érdekelnek, részletek itt.)

Most a megváltozott adatbázisunkat szeretnénk visszatölteni a Szerverre. Ha klónozással szereztük az adatbázist, akkor ehhez csak annyit kell mondanunk, hogy

$ git push

Ha viszont a proba könyvtárunkról az adatbázis újonan készült, akkor a Szerveren a projfelh felhasználó üzemeltetőjének el kell küldeni emailben a proba nevet, hogy tudathassa a Szerverrel, hogy lesz egy ilyen új adatbázis rajta. Ha tudatta vele, akkor a következőket kell tenni:

$ git remote add origin projfelh@valami.szerver.hu:proba.git

ezzel megspórolhatjuk, hogy mindig ki kelljen írni a projfelh@valami.szerver.hu:proba.git -et, helyette csak annyit kell majd írni, hogy origin. Ezután pedig

$ git push origin master

ami szabad fordításban annyit tesz, hogy légy szíves az előbb definiált origin nevű központi helyre töltsd fel az adatbázisunkat. A master egyelőre az egyetlen ága a központi adatbázisnak, de ezt is be kell írni.

Ha ezután valamikor máskor dolgozni szeretnénk a könyvtárban, akkor (ha épp nincs meg a könyvtárunk benne a ./git adatbázissal, klónozzuk, lásd fent, ha pedig megvan, akkor)

$ git pull origin master

az origin rövidítésű központi adatbázis master ágával (egyelőre ez az egyetlen) frissíti a saját könyvtárunkat (ha kell).

Ha sokan piszkálták egyszerre a proba könyvtárat és fel-le töltögettek a központi adatbázisba, a Git legtöbbször olyankor is tudja frissíteni a saját könyvtárunkat (pull) vagy a központi könyvtárat (push), kitalálja hogyan egyesítse a változásokat. Ha ez mégsem sikerülne, klikk ide, ide vagy ide.

Ha nem vagyunk elég bátrak, pull helyett lehet a következőket is csinálni:

$ git fetch
$ git diff master..origin/master

ez nem írja át a könyvtárunkban a fileokat, de megmutatja mi a különbség a Szerver verziója és a mi verziónk között. Ha a helyzet jó, akkor

$ git merge master origin/master

átvezeti a változásokat. Ha ez mégsem sikerülne, klikk ide, ide vagy ide.

Ha el vagyunk tévedve, vagy valami nem világos, segíthetnek a következők:

$ git status


$ git diff

megmutatja mi változott, de még nem volt rá add,
$ git diff --cached

megmutatja mi lesz commit-olva.


Verziókezelés. Történelem:

$ git log

történelem (bővebben).

Minden egyes commitnak lesz egy ronda neve, ezt pl. a git log megmutatja. Ha kiváncsiak vagyunk milyen fileok tartoznak az adatbázisunkhoz,

$ git ls-tree master
$ git ls-tree [a ronda név első pár karaktere]

Ha nem adtunk meg elég sok karaktert, a Git panaszkodik, adjunk meg még párat a ronda névből. Ha kiváncsiak vagyunk két commit közti különbségre,

$ git diff [ronda név]..[ronda név]

Ha valamelyik korábbi verziót megint megnéznénk,

$ git checkout [a ronda név első pár karaktere]

Ekkor a könyvtárunkban visszaáll a ronda nevű commitnak megfelelő állapot. Ne ijedjünk meg, nem vesztettük el amit azóta írtunk, egy

$ git checkout master

visszaállítja a legutóbb commitolt verziót a könyvtárunkban.


Elágazás. Tegyük fel, hogy kipróbálnánk valamit, de nem vagyunk biztosak benne, hogy jó lesz a vége. Ekkor elágazhatunk:

$ git branch kiserleti

ez létrehozott egy kiserleti ágat a könyvtárunkból. Ha ezen akarunk dolgozni,

$ git checkout kiserleti

majd változtassunk a könyvtárunkon, ezután a szokásos

$ git add .
$ git commit

elkönyveli a változásokat a kísérleti ágban. Bármikor visszatérhetünk a fő ágra:

$ git checkout master

Melyik ágban vagyunk is tulajdonképpen:

$ git branch

Mi különbözik az ágakban:

$ git diff master..kiserleti

Ha írtuk kicsit a kísérleti ágat, esetleg a fő ágat is, és a kísérlet jól sikerült, akkor beolvaszthatjuk a fő ágba:

$ git merge kiserleti

Ha a merge mégsem sikerülne, klikk ide, ide vagy ide. Sikeres merge után a kísérleti ágat kitörölhetjük (persze nem a történelemből):

$ git branch -d kiserleti

Ha viszont a kísérlet befuccsolt, és nyomtalanul el akarjuk tüntetni (a történelemből is), akkor

$ git checkout master
$ git branch -D kiserleti


Tisztítás / tömörítés. Előfordulhat, hogy a .git könyvtárunk túl nagyra nőtt, vagy már felesleges objektumokat tartalmaz. (Ez ténylegesen meg is történik, ha különböző gépeken tárolt .git könyvtárakat a Git tudtán kívül szinkronizálunk.) Ezen segít egy tömörítés/tisztítás:

$ git gc

Elkerülendő a "Jaj mégsem kellett volna kitörölnöm" problémákat olyan .git-beli objektumokkal amiket amúgy a Git a hatóköréből már kiiktatott, a git gc csak a két hétnél régebbi és a Git adatbázisában már feleslegessé vált objektumokat törli. (Tehát nem a két hétnél regebbi verziókat, azok természetesen megmaradnak git gc után is.) További részletek itt.



GITHUB

AGitHub egyfajta közösségi tér is. Regisztrált felhasználóként feliratkozhatunk az egyes projektekhez megfigyelőként, így értesülhetünk a projektet érintő változásokról.

Ez, mint a nyílt forrású projektek Facebook-ja.

A történések itt is egy newsfeed-ben gyűlnek össze, minden felhasználónak van profilja,
 Csak bekattintjuk a projektet, és már ott is van a newsfeed-ben.

Ez egyébként az egész rendszerre igaz, hogy az egyszerű és logikus felépítésre törekedtek, nem kell geek-nek lenni a használatához (pl. nem kell RSS feed-ekkel bajlódni).

A GitHub igazán nagy dobása azonban nem a könnyű használhatóság, vagy a szociális háló szerű felépítés, hanem a rendszer nevét is adó Git nevű verziókezelő hatékony használata.

A GitHub-on nem egy központi repository-ba dolgoznak a fejlesztők.

Mindenkinek saját lokális repository-ja van. Ide tologatja be a módosításokat, majd ha kész van egy részfeladat, a munkáját beszinkronizálja egy  központi repositroy-ba.

Mivel ez a repository is pont olyan, mint a lokális, ezért akár ennek a tartalmát is betolhatjuk egy harmadik repository-ba, és így tovább, akár egész bonyolult hierarchiákat is felépítve ezekből. Ezek a repository-k ráadásul teljesen egyenértékűek, és nem csak “tolni” lehet a változásokat, hanem “húzni” is.

Tehát ha van egy repository-nk, annak a tartalmát vagy “kitoljuk” (push) a másik repository-ba, vagy a másik repository-ból “húzzuk” át (pull) a változásokat.

Egy hagyományos, SVN-t használó open source projektnél ha szeretnénk hozzájárulni a projekthez új fejlesztéssel, vagy hibajavítással, akkor le kell töltenünk a repository tartalmát, elvégezni a módosításokat, majd generálni egy patch-t. Ezt aztán e-mailben, vagy a hibajegy kezelő rendszeren keresztül eljuttatni a fejlesztőkhöz, akik aztán vagy merge-ölik ezt a projektbe.

Ha itt valaki hozzá akar járulni egy projekthez, egyszerűen leklónozza (forkolja) azt. Így egyetlen gombnyomásra élből lesz egy saját repository példánya a projektből (ezt a Git azért okosan tárolja, hogy ne legyen nagy a redundancia).

 A saját repository-val aztán azt tesz a fejlesztő, amit akar. Alapesetben végrehajtja a fejlesztést, majd (és itt van a trükk) a projekt gazdájának küld egy pull request-et. Ez tulajdonképpen egy rendszeren belüli üzenet, amiben a hozzájáruló fejlesztő leírja, hogy milyen fejlesztéseket/hibajavításokat végzett.

 Ha a projekt gazda egyet ért a fejlesztésekkel, akkor áthúzza azt a saját repository-jába (ilyenkor szükség lehet merge-ölésre, amiben viszont a Git eleve jobb, mint az SVN). 

A lényeg tehát, hogy itt nem kell patch-eket generálgatni, nem kell levelezgetni, mindent ellehet intézni néhány kattintással a rendszeren belül, ez pedig egy sokkal barátságosabb módja a projekthez való hozzájárulásnak.

Indulásnak GitHub kliens program telepítése szükséges, amivel néhány kattintással létrehozhatunk egy lokális repository-t a számítógépünk egyik mappájában, amit aztán ugyancsak pár kattintással fel is tölthetünk a GitHub-ra. 

Ez igazából alapvető számítógépes ismereteknél nem kíván sokkal többet, így a segítségével bárki könnyen kihasználhatja a GitHub által szolgáltatott lehetőségeket. Ha feltöltöttük a projektünket, az Admin oldalon nagyon pofás kis honlapot generálhatunk neki, ami ráadásul ugyanúgy Git-ben tárolódik, tehát később a hozzájárulók a programkódhoz hasonlóan a honlap tartalmát is bővíthetik, vagy javíthatják.

Megjegyzések