De mégis mit nyújt egy ilyen project hosting rendszer, és mi az ami ezek közül kiemeli a GitHub-ot? Egy project hosting rendszer többnyire mindent készen nyújt, ami egy nyílt forrású rendszer publikálásához, és karbantartásához kell. Alapvetően mindenhol kapunk egy verziókezelő rendszert, valamilyen hibajegy kezelő rendszert (issue tracker), és valami wiki féleséget, ahol leírásokat és dokumentációt készíthetünk a rendszerhez. Így tulajdonképpen minden adott, ami egy ilyen projekt futtatásához szükséges. De mi az, amiben a GitHub különleges? Először is, más rendszerekkel ellentétben a GitHub 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. Ha nagyon hasonlítani akarnám valamihez, azt mondhatnám, hogy olyan 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, stb. Igazából mindezek a lehetőségek más rendszerekben is adottak, de míg mondjuk a Google rendszerében RSS feed-ekkel kell bajlódnunk, addig itt tényleg minden olyan könnyedén megy, mint Facebook-on. 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 Git egy elosztott verziókezelő rendszer. Ilyenekről már írtam kicsit a Mercurial kapcsán. Röviden annyi a lényeg, hogy más központosított rendszerekhez képest (pl. SVN) itt nem egy központi repository-ba dolgoznak a fejlesztők. E helyett 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. Igazából a Git-ről nagyon sokat lehetne írni, de nem akarok nagyon elkalandozni ebbe az irányba, mivel a bejegyzés célja a GitHub rövid ismertetése. De lássuk, miért is olyan jó nekünk ez a Git? 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, vagy nem. Ez összességében elég nagy macera (patch generálgatás, levelezgetés, stb.), és jó eséllyel el is megy a fejlesztő kedve a projekthez való hozzájárulástól. A GitHub-on viszont találtak erre egy nagyon jó megoldást, amit a Git tesz lehetővé. 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.
Most, hogy ismerjük a GitHub alapvető logikáját, lássuk mi kell a használatához. Ha Windows rendszert használunk, akkor a legegyszerűbb, ha letöltjük a GitHub klienst. Ez egy kis program, 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íthatik, vagy javíthatják.
Hát, körülbelül ennyit szerettem volna írni a GitHub-ról. Látható, hogy igazából nem kapunk semmi olyat, amit így vagy úgy ne lehetne más rendszerekkel megvalósítani, ugyanakkor tény, hogy egy rendszert sem ismerek, ami a GitHub-nál egyszerűbb és kényelmesebb módon valósítaná meg mindezt. Ezért gondolom, hogy a GitHub a jelenleg elérhető legjobb projekt hosting rendszer, és ezért gondolják ezt mások is (pl. az Android forráskódját is a GitHub hosztolja). Remélem sikerült egy kis kedvet csinálni a rendszer kipróbálásához, és majdani használatához.
Időközben készült még egy írás Git és GitHub témakörben, ami kicsit jobban körbejárja a rendszer működését. Ha érdekel, itt elolvashatod: https://medium.com/envienta-magyarorsz%C3%A1g/git-%C3%A9s-github-gyorstalpal%C3%B3-f2d78a732deb
Akit bővebben érdekel a téma, annak +Balazs Nadasdi Csapatmunka GitHub segítségével című írását ajánlanám a továbblépéshez. Ez egy nagyon átfogó (szerintem jelenleg a magyar nyelven elérhető legátfogóbb) leírás a témában.