1. témakör · Alapok és munkakörnyezet · 1. fejezet
Mielőtt kiadnánk az első git parancsot, tisztázzuk, milyen
problémát old meg a verziókezelés, milyen típusai vannak, hogyan született meg a
Git — és mi a különbség a Git és a GitHub között.
Biztosan láttál már ilyen mappát — talán a sajátodat. Egy iskolai weboldal-projekt néhány hét után valahogy így néz ki, ha kézzel próbáljuk menteni a változatokat:
Ugyanez a projekt verziókezeléssel:
$ git log --oneline e41b7c2 (HEAD -> main) Kapcsolat űrlap ellenőrzése 9a0d3f1 Mobilnézet javítása 5c27e8a Galéria oldal hozzáadása b81f0d4 Menü és lábléc elkészítése 2f6a9c3 Első változat: kezdőlap
Egyetlen mappa, benne mindig a legfrissebb állapot — a korábbi változatok pedig bármikor visszanézhetők, összehasonlíthatók és visszaállíthatók. (A parancsot a 8. fejezetben tanuljuk meg; most csak az eredményt nézzük.)
| Kérdés / probléma | Kézi mentésekkel | Verziókezelővel |
|---|---|---|
| Melyik a legfrissebb változat? | Találgatás a fájlnevek és dátumok alapján | Mindig a munkamappa az aktuális állapot |
| Mi változott két változat között? | Két mappát kézzel kell összevetni | Soronként megmutatja a különbséget |
| Ki és mikor változtatott, és miért? | Nem derül ki | Minden változáshoz szerző, időpont és üzenet tartozik |
| Elrontottam — vissza tudok lépni? | Csak ha véletlenül volt mentés | Bármelyik korábbi állapot visszaállítható |
| Ketten dolgozunk ugyanazon | Felülírjuk egymás munkáját, e-mailben küldözgetjük a fájlokat | A változások összefésülhetők, az ütközéseket jelzi |
| Ki szeretnék próbálni egy ötletet | Újabb másolat a mappáról | Külön ágon (branch) kísérletezhetek |
A verziókezelés bármilyen szöveges fájlnál remekül működik: forráskód, weboldal, konfigurációs fájl, dokumentáció, de akár egy regény kézirata is. Képeknél és más bináris fájloknál is menti a változatokat, de soronkénti különbséget nem tud mutatni.
A verziókezelő rendszer (angolul Version Control System, röviden VCS; magyarul verziókövetőnek is hívják) olyan szoftver, amely nyilvántartja egy projekt fájljainak változásait az idő során, így bármikor visszanézhető vagy visszaállítható egy korábbi állapot.
A projekt teljes nyilvántartását a tároló, angolul repository (röviden repo) tartalmazza. Ha elértünk egy értelmes állapotot, azt egy commit („rögzítés”) segítségével elmentjük. Egy commit ezeket tartalmazza:
9a0d3f1.user.name, user.email).Sok régebbi rendszer csak a fájlok különbségeit tárolta. A Git ezzel szemben minden commitnál a teljes projekt pillanatképét (snapshot) rögzíti. Ez nem pazarló: ha egy fájl nem változott, nem tárolja újra, csak hivatkozik a korábbi, azonos tartalomra.
Egy webshop kosar.js fájljának öt commitja. Kattints
a commitokra! Zölddel az előző változathoz képest hozzáadott, pirossal a
törölt sorok látszanak. Ki és mikor rontotta el a kedvezmény számítását?
Aszerint, hogy hol tárolódik a projekt története, három nagy csoportot különböztetünk meg.
A legelső rendszerek (pl. SCCS, RCS) csak a saját gépen, fájlonként tartották nyilván a változásokat. Egyedül dolgozva hasznosak, de a csapatmunkát nem támogatják, és ha a gép tönkremegy, minden elvész.
A teljes történet egyetlen központi szerveren van. A fejlesztők onnan kérik le a fájlok aktuális változatát (munkapéldány), és oda küldik vissza a változtatásaikat. Ilyen a CVS, a Subversion (SVN) és a Perforce.
Minden fejlesztő gépén megvan a teljes tároló, a teljes történettel együtt — nem csak az aktuális fájlok. Ilyen a Git, a Mercurial és a Bazaar. A gyakorlatban a csapatok itt is kijelölnek egy közös tárolót (például a GitHubon), amelyen keresztül szinkronizálják a változásokat — de ez csak egy a sok teljes értékű másolat közül.
Az elosztott rendszer nem jelenti azt, hogy minden módosítás azonnal, magától megjelenik a többieknél az interneten. A szinkronizálást mindig mi kezdeményezzük (feltöltés és letöltés — ezek a 18. fejezet témái). Az sem igaz, hogy kevesebb tárhelyet igényel: mivel mindenkinél ott a teljes történet, inkább több helyet foglal.
| Központosított (CVCS) | Elosztott (DVCS) | |
|---|---|---|
| Hol a teljes történet? | Csak a központi szerveren | Minden fejlesztő gépén + a közös tárolón |
| A fejlesztő gépén | Munkapéldány (aktuális fájlok) | Teljes tároló (repository) |
| Commit hálózat nélkül | ✗ | ✓ |
| Ha a szerver tönkremegy | A történet elveszhet | Bármelyik másolatból helyreállítható |
| Példák | CVS, Subversion (SVN), Perforce | Git, Mercurial, Bazaar |
Döntsd el mindegyik állításról, melyik modellre igaz!
A Git egy nagyon konkrét vészhelyzetből született — a világ egyik legnagyobb nyílt forráskódú projektje, a Linux-kernel fejlesztése közben.
A Linux-kernelt 2002-től a BitKeeper nevű elosztott verziókezelővel fejlesztették. A BitKeeper fizetős, zárt forráskódú termék volt, de a kernel fejlesztői ingyenesen használhatták. 2005 áprilisában ezt az ingyenes licencet — a fejlesztőcég és a közösség közti vita után — visszavonták. A Linux megalkotója, Linus Torvalds nem talált olyan szabad rendszert, amely elég gyors és elég jól kezelte volna a több ezer fejlesztő munkáját, ezért megírta a sajátját.
A munka 2005. április elején kezdődött, és néhány nap múlva a Git már saját magát verziókezelte. Két hónappal később már a kernel egy teljes kiadását kezelték vele. Torvalds a tervezésnél ezeket a célokat tűzte ki:
2005 júliusában Torvalds átadta a projekt karbantartását Junio Hamanónak, aki azóta is a Git vezető fejlesztője.
A git a brit szlengben nagyjából „csökönyös, kellemetlen, modortalan alak” jelentésű szó. Torvalds önironikusan magáról nevezte el: azzal viccelődött, hogy minden projektjét saját magáról nevezi el — előbb a Linuxot, aztán a gitet. A Git saját leírása „the stupid content tracker”-nek (a buta tartalomkövetőnek) nevezi magát, a rajongók pedig utólag kitalálták rá a Global Information Tracker „rövidítést” is.
master helyett main lesz; a Gitben (2.28-tól) ez beállíthatóvá válik.A két nevet sokan összekeverik, pedig két különböző dologról van szó:
git …) vagy grafikus programokból használjuk,A Git és a GitHub viszonya olyan, mint a fényképezőgép és egy online fotóalbum. A fényképezőgéppel (Git) bárhol, internet nélkül is készíthetsz képeket (commitokat). Az albumba (GitHub) feltöltve biztonságban vannak, megmutathatod őket másoknak, és közösen is dolgozhattok velük. Fényképezni album nélkül is lehet — de album nélkül nehéz megosztani a képeket.
A GitHub a legnépszerűbb, de nem az egyetlen ilyen szolgáltatás. Hasonló, Git-tárolókat kezelő platformok: GitLabBitbucketAzure DevOps ReposGitea — amit ebben a tananyagban a GitHubról tanulsz, az nagyrészt ezekre is igaz.
A Subversion és a Mercurial nem GitHub-szerű szolgáltatás, hanem másik verziókezelő program — a Git „vetélytársai”.
Melyikre jellemző az állítás: a programra vagy a webes szolgáltatásra?
A következő fejezetekben ezekkel a szavakkal fogunk dolgozni. Most elég, ha nagyjából tudod, melyik mit jelent — mindegyiket részletesen, kipróbálva is megtanuljuk.
| Fogalom | Röviden | Részletesen |
|---|---|---|
| repository (repo) | A projekt tárolója a teljes történettel. Lehet helyi (local, a gépeden) vagy távoli (remote, pl. a GitHubon). | 5. és 17. fejezet |
.git mappa | A projekt mappájában lévő rejtett mappa — itt tárolja a Git a teljes verziótörténetet. | 5. fejezet |
| commit | Egy rögzített állapot (pillanatkép) a projekt történetében, üzenettel. | 6–7. fejezet |
| hash | A commit egyedi azonosítója (SHA-1), pl. 9a0d3f1. | 8. fejezet |
| branch (ág) | Párhuzamos fejlesztési vonal — egy ötlet kipróbálható anélkül, hogy a fő vonalat elrontanánk. | 11. fejezet |
| main / master | Az alapértelmezett, fő ág neve (régen master, ma általában main). | 11. fejezet |
| merge | Két ág összefésülése, mindkét ág történetének megtartásával. | 12. fejezet |
| clone | Egy távoli tároló teljes lemásolása a saját gépre. | 17. fejezet |
| push / pull | push: a helyi commitok feltöltése a távoli tárolóba · pull: a távoli változások letöltése a helyibe. | 18. fejezet |
| fork | Más projektjének másolata a saját GitHub-fiókodban — így hozzájárulhatsz a fejlesztéséhez. | 22. fejezet |
| pull request (PR) | Kérés a tároló gazdájának: „nézd át és olvaszd be a módosításaimat”. | 20. fejezet |
Jegyezd meg már most: a push felfelé visz (a gépedről a távoli tárolóba), a pull lefelé hoz (a távoliból a gépedre). A clone egyszeri, legelső letöltés, amikor még nincs helyi másolatod.
A Gitet többféle felületről is használhatjuk — mögöttük mindig ugyanaz a Git dolgozik. A tananyagban minden fontos műveletet kétféleképpen is megnézünk: parancssorból és grafikus felületről. A fejezetek címkéi mutatják, melyik felületet használjuk.
| Címke | Eszköz | Mire jó? |
|---|---|---|
| CLI | Parancssor: PowerShell, Git Bash, a VS Code terminálja | Minden Git-funkció elérhető, pontosan látszik, mi történik. A hibaüzenetek és a súgó is itt a legbeszédesebbek. |
| Desktop | GitHub Desktop, valamint a VS Code és a Visual Studio beépített Git-panelje | Kattintással commitolhatsz, ágat válthatsz, és jól áttekinthetők a változások. |
| Web | github.com a böngészőben | Távoli tárolók, pull requestek, Issues, beállítások, közös munka. |
A grafikus felület kényelmes, de csak a leggyakoribb műveleteket tudja. A parancssor mindenhol ugyanúgy működik: más gépen, szerveren, bármilyen fejlesztőkörnyezetben. Aki érti, mit csinál a parancs, az a grafikus gombok mögé is belát.
⭐ alap · ⭐⭐ haladó · ⭐⭐⭐ kihívás — füzetben vagy szövegszerkesztőben dolgozz, a megoldásokat az órán beszéljük meg.
Sorolj fel három problémát, amely verziókezelés nélkül előfordulhat, ha hárman dolgoztok ugyanazon a weboldalon!
Egészítsd ki: A Gitet ____________ készítette ______-ben, a ____________ fejlesztéséhez, miután a korábban használt ____________ ingyenes licencét visszavonták.
Magyarázd el két-három mondatban egy osztálytársadnak, mi a különbség a Git és a GitHub között! Találj ki hozzá egy saját hasonlatot (ne a fényképezőgépeset)!
Rajzold le a központosított és az elosztott modellt három fejlesztővel! Jelöld, hol van meg a teljes történet, és hol csak a munkapéldány!
Egy cég szervere leég, és nincs róla biztonsági mentés. Mi történik a projekt történetével, ha a cég Subversiont használt, és mi, ha Gitet? Indokold!
Nyisd meg a böngészőben a github.com/git/git oldalt (a Git saját
forráskódjának tükre)! Keresd meg: hány commit van benne, és mikor volt a legutóbbi? Görgesd
le a commitlistát a legelejéig — mi a legelső commit üzenete?
Egy háromnapos iskolai projektben elkészítitek az osztály bemutatkozó weboldalát (kezdőlap, galéria, kapcsolat). Írj öt olyan commitüzenetet időrendben, amelyekből a haladás pontosan követhető! Mitől jó egy commitüzenet? (A 7. fejezetben visszatérünk rá.)
Az egyválasztós kérdéseknél kattints a válaszra. A többválasztósaknál jelöld be az összes helyeset, majd nyomd meg az Ellenőrzés gombot. A végén pontszámot kapsz.
| Fogalom | Jelentés |
|---|---|
| verziókezelő rendszer (VCS) | szoftver, amely nyilvántartja a projekt fájljainak változásait, és lehetővé teszi a korábbi állapotok visszaállítását |
| repository (tároló, repó) | a projekt fájljai a teljes változástörténettel együtt |
| commit | a projekt egy rögzített állapota: pillanatkép + szerző + időpont + üzenet + hash |
| pillanatkép (snapshot) | a projekt összes fájljának állapota egy adott pillanatban; a változatlan fájlokra a Git csak hivatkozik |
| hash (SHA-1) | a commit tartalmából számolt, 40 hexadecimális jegyű egyedi azonosító; röviden az első 7 jegye |
| történet (history) | a commitok időrendi láncolata |
| munkapéldány | a fájlok aktuális változata a fejlesztő gépén (központosított rendszereknél csak ez van helyben) |
| központosított VCS (CVCS) | a teljes történet egyetlen szerveren van; pl. CVS, Subversion |
| elosztott VCS (DVCS) | minden fejlesztőnél teljes tároló van, a közös tárolón keresztül szinkronizálnak; pl. Git, Mercurial |
| Git | ingyenes, nyílt forráskódú, elosztott verziókezelő program (Linus Torvalds, 2005) |
| GitHub | webes szolgáltatás Git-tárolók tárolására és közös fejlesztésre (2008 óta, 2018 óta a Microsofté) |
| helyi / távoli tároló | local: a saját gépen lévő repó · remote: szerveren (pl. GitHubon) lévő repó |
| nyilvános / privát tároló | public: bárki megnézheti és klónozhatja · private: csak a meghívottak látják |
| main / master | az alapértelmezett fő ág neve (ma általában main) |
A következő fejezetben feltelepítjük a Gitet és a GitHub Desktopot, és elvégezzük az első, kötelező beállításokat.