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
Megjegyzés küldése