1.1.

Üdvözlünk
Üdv a "Tanuld meg az alap Git-munkamenetet" című modulunkban.

Mostanra már biztosan babráltál ezt-azt a Git segítségével, de eljött az ideje,

hogy rendesen elsajátítsd használatának alapjait. A Git az egyik legfontosabb
eszköz a fejlesztők életében. Nem számít, hogy egy multinál dolgozol-e, vagy
csak a szabadidődben kódolsz – szükséged lesz a Gitre.

Ebben a modulban az alábbiakról fogsz tanulni:

 mi is az a Git és a GitHub,
 hogyan kell GitHub-profilt létrehozni,
 mi az a repository, és hogyan lehet létrehozni,
 hogyan férhetsz hozzá a GitHubon tárolt munkáidhoz a saját gépedről,
 hogyan követheted a változásokat a kódodban, és tudhatod biztonságban
az egyes verzióit,
 hogyan tudsz másokkal együtt dolgozni ugyanazon a kódon,
 mi is az a parancssor, és hogyan használhatod mindenféle Git-
varázslathoz.

Dióhéjban: megtanulhatod a Git használatának alapjait, hogy kordában tudd

tartani a komplexebb projektjeidet is.

Készen állsz? Akkor csapjunk bele!

1.2. A Gitről röviden

Mielőtt rátérünk a gyakorlati tudnivalókra, fontos tisztában lenned azzal, hogy
mi is az a Git, illetve a GitHub, és mire használjuk ezeket pontosan. Mindez nem
lesz több 5 percnél, és még akkor is érdemes átfutnod, ha korábban már
találkoztál a Gittel.

Mi is a Git?

A Git egy "ingyenes és nyílt forráskódú verziókezelő rendszer" (version control

system, VCS). A VCS lehetővé teszi számodra, hogy tárold a projekted különböző
verzióit (iterációit), ahogy haladsz előre a munkával. Ezt
hívjuk verziótörténetnek (version history). A verziótörténet segítségével
összehasonlíthatod az egyes iterációkat, láthatod, hogy pontosan mi változott és
mikor, illetve akár vissza is térhetsz egy korábbi – működő – állapothoz, ha
valami nagyon félremenne.
Más szóval: bármikor megkérheted a Gitet, hogy készítsen egy biztonsági
másolatot a projekted valamennyi fájljáról és mappájáról, és ezt őrizze meg.
Ezekhez a mentésekhez később bármikor hozzáférhetsz, így biztosan semmi
sem veszik el a munkádból.

Megjegyzés: Egy másik nagyszerű dolog a Gitben, hogy képes hibátlanul

nyomon követni és összefésülni többek változtatásait ugyanazon a projekten,
így rendkívül könnyűvé teszi azt, hogy többen is dolgozzanak ugyanazon a
kódon. Ez csapatokban iszonyú hasznos, de mi egyelőre csak a verziókontroll
részre fogunk koncentrálni. Hiszen egyelőre egyedül dolgozol.

Hogy működik a Git?

Minden új projekt egy repository-val (tárolóval) kezdődik a Gitben. Képzeld el a

repositoryt úgy, mint egy dobozt, ami összegyűjti a projekteddel kapcsolatos
valamennyi fájlt és mappát. A Git ezt a "dobozt" elsőként egy távoli szerveren
tárolja – ez lesz a projekted "mesterpéldánya" (master copy).

Következő lépésként ezt a repositoryt a gépedre másolod (ezt klónozásnak

hívják). A Git mindkét verzióját követi a repositorynak: a helyi verziót a gépeden,
a távolit pedig a szerveren.

Ettől kezdve szabadon megváltoztathatsz bármit a helyi repositoryban. Amikor

pedig úgy érzed, megkérheted a Gitet, hogy a változtatásaid adja hozzá a távoli
repositoryhoz, ezzel egy új verziót létrehozva a projektedből.

Ekkor a Git készít egy biztonsági mentést a távoli repositoryról, majd

összehasonlítja a helyi kódod a szerveren tárolttal. Megkeresi, hogy mit
változtattál meg, és ezeket összefésüli a távoli repositoryban lévő kóddal.

Amikor végzett, a helyi és távoli repositoryd tartalma megegyezik, létrejön egy

új verziója a projektednek, az előző verzió pedig biztonságban csücsül a távoli
szerveren.

Azt hiszem, nem kell sokat magyarázni, hogy ez miért nagyon hasznos. Hála a
Gitnek, nyugodtan dolgozhatsz a kódod helyi verzióján, abban a tudatban, hogy
a fő másolat biztonságban van a felhőben. Ezen felül hozzáférhetsz bármikor a
korábbi verziókhoz, ha valami rosszul sül el, van biztonsági mentésed, és ha
tudni akarod, hogy mikor mi változott, mindenről van feljegyzésed.

A Git akkor is segít, ha többen dolgoznátok ugyanazon a kódon. Lehetséges az,

hogy a távoli szerveren található repositoryhoz nem csak te, hanem más is
hozzáférhet és közösen tudtok dolgozni.
Megjegyzés: A gyakorlatban általában minden nagyobb változtatásnál
készítünk egy új verziót a kódból, de a pontos módszerre még visszatérünk egy
kicsit később a projektben.

Mi is a Git?

A Git egy távoli szerver, amely repositorykat tárol.

A Git egy asztali kódszerkesztő, amely megmutatja a legutóbbi
változtatásokat a kódodban, amíg el nem mented azokat.
A Git egy verziókezelő rendszer (version control system), amely lehetővé
teszi számodra, hogy a projekted különböző verzióit tárold és összehasonlítsd
egymással, vagy akár visszaállíts egy korábbi állapotot.
A Git egy verziókezelő rendszer, amely lehetővé teszi számodra, hogy
összehasonlítsd a kódod helyi és távoli változatát, és a helyi változtatásokat
hozzáadd a távoli repositoryhoz. Miután így felülírod a távoli szerveren lévő
változatot az új verzióval, a kódod régebbi állapota hozzáférhetetlenné válik.

1.3. A GitHubról röviden

Mi az a GitHub?

Nagyon leegyszerűsítve: a GitHub az a távoli szerver, amely a repositorykat

tárolja.

Ennél persze sokkal több. A GitHub a fejlesztői közösség egyik legtöbbet

használt oldala, amely számtalan módon segíti mind csapatok, mind egyének
munkáját. Egyelőre azonban bőven elég, ha annyit tudsz róla, hogy egy kódot
tároló szolgáltatás, amely a Gitet használja alapként.

Megjegyzés: Rengeteg másik szolgáltatás létezik még, amely Gitet használ

projektek követésére. Azért választottuk a GitHubot, mert messze ez a
legnépszerűbb közöttük, és nyílt forráskódú projektek esetén ingyenes.

Dióhéjban

Ha Gitet és GitHubot használsz, soha nem kell attól félned, hogy elveszted a
kódod, vagy véletlen eltöröd a projekted mesterverzióját.

No, most, hogy ez már mind világos, elkezdhetjük felállítani a rendszert.

Elsőként mutatunk néhány trükköt a fájlrendszerben való navigáláshoz
parancssorból. Ez ugyanis elengedhetetlen lesz a Git kezeléséhez.
Vágjunk is bele.
Mi a különbség a Git és a GitHub között?

Semmi, a Git a GitHub rövidítése.

A Git egy programozási nyelv, a GitHub pedig egy fórum, ahol más
fejlesztőkkel beszélgethetsz a Gitről.
A Git egy asztali szövegszerkesztő, míg a GitHub egy online kódszerkesztő.
A Git egy verziókezelő rendszer (version control system), a GitHub pedig egy
szolgáltatás, amely távoli tárhelyet biztosít repositoryk számára, és a Gitet
használja ehhez alapként.
Ellenőrzöm a válaszom

Ez igazán szép megoldás volt. Büszke lehetsz magadra!

2.1. A parancssor kezelése

A parancssor (CLI) egy hasznos eszköz minden számítógépen, amellyel
mindenféle műveletet (fájlok és mappák manipulációja, programok indítása stb.)
végezhetsz el szöveges parancsok segítségével. A parancssort több különböző
programon keresztül is el lehet érni, hasonlóan ahhoz, ahogy több különböző
böngészőt is használhatsz az internetezéshez.

Mi a parancssort fogjuk felhasználni a Git megismeréséhez és kezeléséhez. Ide

fogjuk majd beírni a parancsokat, amelyekkel utasításokat tudunk adni a Gitnek.
A konkrét utasításokra a további leckékben fogunk kitérni.

Az egyszerűség kedvéért mi most az operációs rendszerek alapértelmezett CLI-

jait (command line interface, azaz parancssori kezelőfelület) fogjuk használni:

 Macen a Terminalt,
 Windowson a Powershellt.

A Terminal megnyitásához Macen navigálj az Alkalmazások > Segédprogramok

(Applications > Utilities) menübe, és nyisd meg onnan az alkalmazást, vagy
keresd meg a Spotlight segítségével, és nyomd meg az Entert.

A Powershell megnyitásához nyomd meg a Windows billentyűt a kereső

megnyitásához, és kezdd el begépelni, hogy Powershell. Nyomd meg az Entert,
amikor felugrik a program a listán.

Ahogy látod, ezek valóban teljesen szöveges felületek. Te parancsokat fogsz

begépelni, a géped pedig üzenetekben fog reagálni ezekre. Lehet, hogy most
még bonyolultnak tűnik, de hidd el, ha egyszer megtanulod az alapokat, sokkal
gyorsabban tudsz majd így dolgozni, mint bármilyen grafikus kezelőfelületen.

Hogyan navigáljunk a fájljaink közt

A CLI alapértelmezetten a fájlrendszered legtetején nyílik meg. A pwd (print

working directory, munkakönyvtár kinyomtatása) paranccsal mindig meg tudod
nézni, hogy épp hol vagy. Próbáld ki. Nyisd meg a CLI-t, gépeld be azt, hogy pwd,
és nyomj Entert. Vissza kell kapnod a teljes elérési útját annak a könyvtárnak,
ahol éppen tartózkodsz, valahogy így: Users/your-username (Felhasználók/a-te-
felhasználóneved).

Ez eddig szuper, de még azt is tudnunk kell, hogy milyen egyéb könyvtárak
(mappák) vannak ott, ahol vagyunk, hogy tudjuk, merre tudunk tovább menni.
Erre találták ki az ls (list, listázás) parancsot. Próbáld meg beírni a CLI-odba,
majd nyomni egy Entert.

A parancssor ki fogja írni az összes elérhető könyvtárat a jelenlegi helyzetedben.

Az enyém például most így néz ki:

A következő lépés, hogy a cd (change directory, könyvtár váltása) paranccsal

"elutazz" egy másik könyvtárba. Például én használhatnám a cd
Documents parancsot, amivel bekerülnék a Documents (Dokumentumok)
mappámba.

Próbáld ki ezt is. Válassz egyet a kilistázott mappáidból, és használd

a cd parancsot valamelyiken.

Oké, lépjünk tovább a komolyabb dolgok felé. Ahhoz, hogy elérd a fő Projektek
mappád, először vissza kell menned a kezdőpontra.
Lépj vissza abba a könyvtárba, ahonnan indultunk. Ehhez a cd .. parancsot
tudod használni, ami egy lépéssel mindig feljebb visz a fájlrendszerben. Ez
gyakorlatilag a "Vissza" gomb a CLI-ben.

Tipp: A navigáció során össze is kötheted a lépéseket, ha tudod a teljes elérési

utat. Például ha az én My-projects (Projektjeim) mappám a Documents
(Dokumentumok) mappámon belül lenne, írhatnám ehelyett: cd Documents,
aztán cd My-projects, ezt: cd Documents/My-projects.

Megjegyzés: Ha több meghajtód van és át szeretnél menni egy másikra, akkor

csak elég annyit beírnod, hogy cd D:. A D: itt a másik meghajtót jelöli. Így
könnyen tudsz a meghajtók között átjárni.

Melyik paranccsal tudsz a mappák között váltani?

dc
ls
cd
pwd
Ellenőrzöm a válaszom

Igen, igen, és megint csak igen. Ez a helyes válasz!

3.1. GitHub-regisztráció
A távoli szerveren való tároláshoz elősorban szükséged lesz egy GitHub fiókra.
Ha már regisztráltál, akkor nyugodtan ugord át ezt a leckét, és folytasd a
következővel.

1. lépés: Hozz létre egy fiókot

Nyisd meg a GitHub oldalát, és kattints a „Sign up” (feliratkozás) gombra a jobb
felső sarokban. Egyből át fog irányítani a regisztrációs űrlap első oldalára:

1. Add meg az e-mail-címed. A regisztráció végén kapni fogsz egy

automatikus megerősítő e-mailt, ezért figyelj arra, hogy működő címet
adj meg.
2. Adj meg egy jelszót. Kérlek, ne „jelszó” és „12345” típusú jelszavakat
használj. Sokkal jobb vagy ennél.
3. Válassz egy felhasználónevet. Ne feledd, hogy idővel a GitHub-profilod
egyfajta portfólióként is szolgál majd, amelyet a potenciális munkaadóid
és a fejvadászok még azelőtt lecsekkolnak, hogy találkoznának veled.
Érdemes elkerülnöd az olyan felhasználóneveket, mint „gyilkos_malac”
vagy „izmospisti1981”. Válassz valami egyszerűt és professzionálisat.

Beállíthatod az e-mail-preferenciáidat is, és meg kell erősítened, hogy valódi

személy vagy. Ha kész vagy, nyomd meg a „Continue” gombot a panel alján.

2. lépés: Erősítsd meg az e-mail-címed

Az új oldalra érve egy számsort kell megadnod. Nyisd meg az e-mail-fiókodat,

keresd meg a levelet a GitHubtól, az üzenetben található kódot pedig gépeld be
az oldalra.

3. lépés: Szabd személyre

Ezen az oldalon megválaszolhatsz néhány egyszerű kérdést, amelyek alapján a
GitHub megpróbálja rád szabni az oldalt. Ha akarsz, rászánhatsz erre egy pár
percet, de akár át is ugorhatod. Tied a döntés.

Gratula, sikeresen regisztráltál a GitHubra!

Feladat:
Mi lett a GitHub-felhasználóneved?

A megoldásod:

VargaSzilvia

3.2. Personal Access Token

A GitHub többféle biztonsági lehetőséget kínál fel a felhasználóinak mind a fiók,
mind a repositoryk védelmére. Az egyik ilyen a Personal Access Token (PAT).

Ahhoz hogy a CLI-ből hozzáférj a GitHubon pihenő mesterverziókhoz, generálni

kell egy Personal Access Token-t. Ez a token engedélyezi neked hogy helyi
változtatásokat alkalmazd a távoli repositoryban.

Pár lépésben megmutatjuk, miként tudsz létrehozni egy ilyen

tokent.

1. lépés: Jelentkezz be a GitHubra

Ha kijelentkeztél az utolsó alkalom óta, akkor nyisd meg a GitHub oldalát és
jelentkezz be a felhasználóneveddel és a jelszavaddal.

2. lépés: A beállítások között keresd meg a PAT generálást

A jobb felső sarokban a felhasználói képedre kattintva egy legördülő menü nyílik
meg. Itt válaszd ki a „Settings” menüpontot.

Az új oldalra érkezve egy kicsit lejjebb kell, hogy görgess addig a pontig, amíg
meg nem látod a „Developer settings” menüpontot a bal oldali oszlopban.

Ez ismét átvitt egy új oldalra.

1. A bal oldali panelből válaszd ki a „Personal access tokens” menüpontot.

2. Végül pedig kattints a „Generate new token” gombra.
3. Miután ezt megtetted, a GitHub újból elkéri a jelszavad.

3. lépés: A token személyre szabása

Ezen az oldalon egy részletes beállítást hajthatsz végre az új tokenen.

1. Nevezd el a tokent. Törekedj olyan név megadására, amely utal a token

tartalmára. Például: CLI token.
2. Adj meg egy lejárati dátumot a tokennek. A javaslatunk az, hogy válaszd
ki a No expirationt. Ha bármelyik másik értéket választod, akkor a beállított
idő előtt a GitHub küldd egy emailt és egy új tokent kell majd generálnod.
3. Ezen a ponton számos finomhangolást adhatsz meg a tokennek.
Egyenlőre pipáld be a „repo”-t.

A token generálásához görgess az oldal aljára, itt találsz egy zöld „Generate
token” gombot. Kattints rá!

4. lépés: A token mentése

Ha minden rendben ment, erre az oldalra fogsz érkezni:

Fontos! Mielőtt bármit csinálnál, mentsd le a generált karaktersorozatot egy
biztonságos helyre. Ez lehet a gépeden egy szöveges dokumentum, vagy egy
papírra felírt jegyzet.

Egyelőre ennyi! A következő lépésként szükséged lesz a Git telepítésére a

számítógépeden. Ezért a következő leckében ezt fogjuk telepíteni.

3.3. A Git telepítése

Hogy használni tudd a Gitet, telepítve kell lennie a gépeden.

Nézd meg, hogy telepítve van-e már

Előfordulhat, hogy a Git már rajta van a számítógépeden. Ezt egyszerűen

ellenőrizheted, ha a választott parancssori kezelőfelületre beírod azt, hogy git,
és nyomsz egy Entert.

Windowson

1. Nyisd meg a Powershellt, írd be, hogy git --version, és nyomd meg az
Entert.
2. Ha telepítve van a Git, akkor a verziószámot fogod megkapni, ha nincs,
akkor egy hibaüzenetet.
3. Ebben az esetben a legegyszerűbb megoldás az, ha letöltöd a Git for
Windows csomagot.
4. Nyisd meg ezt az oldalt majd kattints a bejelölt linkre. Ez mindig a
legfrissebb verziót fogja letölteni.

5. Nyisd meg a letöltött fájlt, telepítsd a programot, majd indítsd el újra a

Powershellt.
 6. Írd be ismét, hogy git --version. Most már tényleg a verziószámot kell
megkapnod.

Macen

1. Nyisd meg a Terminált, írd be, hogy git, és nyomd meg az Entert.
2. Ha van Git a gépeden, egy hosszú lista fog megjelenni a lehetséges
parancsokról. Ha nincs, akkor pedig egy hiba üzenet fog felugrani.
3. Nincs mást tenni, mint telepíteni kell a Gitet. Nyisd meg ezt az oldalt.
4. A linkre kattintva a letöltés automatikus elindul.
5. Menj végig a telepítési beállításokon.
6. Várd meg, míg a telepítő végez, és már készen is vagy.
7. A Terminálba próbáld meg újból beírni a git parancsot.

Gratula, sikerült telepíteni a Gitet a gépedre. Az utolsó lépés, hogy beállítsuk a

Git-identitásod (személyazonosságod).

3.4. Állítsd be a Git-identitásod

Amikor a Gittel dolgozol, a rendszernek össze kell kapcsolnia a változtatásaidat
egy névvel és e-mail-címmel.

A Git felhasználóneved beállítása

Fontos, hogy ez nem egyezik meg a GitHub felhasználóneveddel. Ezt a nevet

használja a Git, hogy azonosítson téged, és összekösse a változtatásaid a
kódban veled mint egyénnel. Jó gyakorlatnak számít, ha a saját, valós neved
adod meg Git felhasználónévnek.

Nyisd meg a CLI-det, és írd be a következő parancsot:

git config --global user.name "Mona Lisa"

Megjegyzés: Természetesen ne Lisa nevét használd, hanem a sajátodat.

Állítsd be az e-mail-címed

Ez az az e-mail-cím, amit viszont a GitHub használ ahhoz, hogy azonosítson

téged. Használd ugyanazt a címet, mint amivel az oldalon regisztráltál. Nyisd
meg a CLI-t, és írd be a következőt:
git config --global user.email "email@example.com"

Megjegyzés: Természetesen a saját e-mail-címedet használva.

Ennyi!

Ezzel végeztél is a Git beállításával. Ettől fogva mindent el tudsz végezni

közvetlenül a parancssorból. Gratula!

4.1. Bevezető
Most, hogy minden készen áll – regisztráltál GitHubra és a Gitet is telepítetted –
itt az ideje megismerned, hogyan fogunk ezekkel az eszközökkel dolgozni.

Az alap Git-munkafolyamat (Git workflow) egymás utáni lépések sorozata, amely

segít komplex projekteket kezelni:

1. Hozz létre egy új repositoryt (röviden: repot) GitHubon.

2. Klónozd le a saját gépedre.
3. Nyisd meg a repositoryt egy kódszerkesztővel. Hozz létre benne
mappákat, fájlokat, majd dolgozz a projekteden.
4. Minden fontosabb mérföldkőnél hozz létre egy új verziót, és töltsd fel a
változtatásokat a távoli repositoryba.

Ebben a fejezetben lépésről lépésre végigmegyünk ezen a folyamaton, és

minden állomást megismersz részletesen is. Közben ezen az egyszerű oldalon
fogsz elkezdeni dolgozni, amelyet a modul későbbi részeiben majd még tovább
formálunk:

Vágjunk is bele!

4.2. Hozd létre az első repositoryd

Ahogy korábban már szó volt róla, a Git lelke a repository: a „doboz”, amely
tartalmazza mindazt, ami egy adott projekthez kapcsolódik. Valahányszor egy új
projektnek állsz neki, érdemes egy új repositoryt létrehoznod, amely tárolni
fogja.

Mindjárt meglátod, hogy repositoryt létrehozni kifejezetten egyszerű. Vágjunk is

bele, és hozzuk létre az elsőt együtt.

1. lépés: Jelentkezz be a GitHubra

Ha kijelentkeztél az utolsó alkalom óta, akkor nyisd meg a GitHub oldalát, és

jelentkezz be a felhasználóneveddel és a jelszavaddal.

2. lépés: Hozz létre egy új repositoryt

Ha még nem csináltál semmit ezen a felületen, akkor ez a kép fogad:

Bal oldalon kattints a „Create repository” (repository létrehozása) gombra:

Megjegyzés: Később, amikor már lesznek létrehozott repositoryjaid, a bal

oldalon a „New” (új) gombra kattintva tudsz majd újat létrehozni. Továbbá,
bármikor indíthatsz új projektet a „Start a project” (egy projekt elkezdése)
gombra kattintva is:
3. lépés: Állítsd be a részleteket

A következő oldalon elnevezheted a repositorydat, és beállíthatsz pár egyéb

dolgot:

1. Nevezd el a repositorydat. Válassz olyan nevet, amely rövid, könnyen

felidézhető, és utal a tartalmára. Ebben az esetben például a „git-basics-
project” jó lehet. (Ha valami félre menne, ne aggódj, a repositoryt
bármikor törölheted majd a jövőben.)
2. Mellékelj egy rövid leírást a projektedről. Ezt nem muszáj megtenned, de
segíthet másoknak megérteni, hogy körülbelül min dolgozol.
3. Állítsd be a repository láthatóságát.
o Egy Public repository-t bárki elérhet.
o A Private repository esetén te döntöd el, hogy ki férhet hozzá.
4. Itt adhatsz a repositoryhoz egy README („olvassel”) és egy .gitignore fájlt,
valamint itt választhatsz ki egy licencet. (Ezeket egyelőre ne válaszd ki,
majd csak később lesznek fontosak.)
5. Ha mindennel elégedett vagy, kattints a „Create repository” (repository
létrehozása) gombra.

4. lépés: Üdv az első repositorydban

Ha minden rendben ment, egy ehhez hasonló oldalra fogsz érkezni:

Megjegyzés: Ezt a felületet akkor láthatod, amikor a repository még üres, tehát
semmilyen tartalom (mappák, fájlok stb.) nincs hozzáadva. Ne ijedj meg tőle, a
neked szükséges részeket a későbbi leckékben majd bemutatjuk.

Amikor már lesznek fent fájlok a repositorydban, egy ehhez hasonló oldalt fogsz
látni:

Ez lesz a repository főoldala. Öt nagyobb részből áll:

 1-3: Ezeket egyelőre nyugodtan hagyd figyelmen kívül, csak később lesz
fontos.
 4: Itt jelennek majd meg a mappáid és fájljaid.
 5: Amennyiben a projektnek van már README fájlja, ennek a tartalma
automatikusan meg fog jelenni itt. Arra szokták használni, hogy némi
információt osszanak meg a projektről, hogy mások megtudhassák, miről
szól.

Egyelőre ennyi – gratulálunk az első repositorydhoz! Emlékeztetőként: amit

most létrehoztál, az a projekted mesterpéldánya. A következő lépés, hogy
létrehozd a repository helyi másolatát a saját gépeden.

Feladat:
Másold ide a repositoryd linkjét.

A megoldásod:

https://github.com/VargaSzilvia/git-basic-project
4.3. Klónozd le
Ha eddig minden jól ment, akkor valami ilyesmit kell látnod a repositorydban:

A léterhozott repository egyelőre csak a GitHubon létezik. Ahhoz, hogy a

gépünkön is használni tudjuk, le kell másolnunk, azaz le kell klónoznunk
(angolul: clone). Ehhez a következő lépések vezetnek:

1. Nyisd meg a parancssort (CLI-t), és navigálj a fő, Projektek mappádba.

2. Menj vissza a böngészőbe, és a „Quick setup” (gyors beállítás) részben
látni fogsz egy URL-t. Ezt másold ki:
o jelöld ki kézzel, vagy
o nyomd meg a „Copy to clipboard” (másolás a vágólapra) gombot a
link mellett.
3. Válts át a parancssorodba. Győződj meg róla, hogy benne vagy a
Projektek mappádban (pwd).
4. Gépeld be a következőt: git clone https://your-url.com, ahol a link helyére
illeszd be az URL-t, amit kimásoltál az előbb.
5. Nyomd meg az Entert.

Tipp: A linket Ctrl + V-vel (vagy Macen Cmd + V-vel) tudod beilleszteni.

Megjegyzés: A Git lehet, hogy kérni fogja a GitHub-jelszavad. Írd be, és nyomj
Entert.

Egy ehhez hasonló üzenetet kell látnod a parancssorban:

Cloning into 'git-basics-project'...

warning: You appear to have cloned an empty repository.
Ha ezt látod, akkor sikeresen klónoztad az első távoli repositorydat a saját
gépedre.

Tipp: Meg is győződhetsz arról, hogy minden rendben ment, ha beírod a CLI-be
az ls parancsot. Az új mappának meg kell jelennie a listában.

Megjegyzés: Ahogy látod, kaptál egy figyelmeztetést (angolul: warning) arról,

hogy egy üres repositoryt klónoztál le. Ez teljesen rendben van, mivel a
repositoryban jelenleg még nincs semmi.

Nem üres repository klónozása

Ha olyan repositoryt klónozol le, ami nem üres (általában ez a jellemző), akkor
az alábbi felülethez hasonló fogad majd:

Itt kattints a zöld „Code” gombra és másold ki repository linkjét:

Ha minden jól ment, akkor az alábbi szöveget fogod a CLI-ben látni:

Cloning into 'git-basics-project'...
remote: Counting objects: 1, done.
remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (1/1), done.

Az alábbiak közül melyik egy helyes git clone parancs?

git clone repository-name
git clone https://your-url.com
git clone
git clone folder-name

Ellenőrzöm a válaszom

Watson, Önnek teljesen igaza van!

4.4. Hozd létre az első fájlodat

Gyors emlékeztetőül – ezt az oldalt szeretnénk megépíteni:

Kérlek, a CLI segítségével navigálj el a git-basics-project könyvtárba. Ezután vedd

elő az asztali kódszerkesztőd, és nyisd meg ott is a mappát.

Megjegyzés: Ha nem igazán ismered az asztali kódszerkesztőket, akkor kérlek,

mielőtt folytatnánk, végezd el az ezekről szóló modulunkat. Máskülönben a
következő részek nagyon gyorsan érthetetlenné fognak válni.

Az első fájl a repositoryban

Ebben a projektben egy nagyon egyszerű honlapot építünk, mindössze
egy index.html és egy style.css fájllal, valamint egy assets mappával és abban egy
képpel. Ezekből nekünk először csak az index.html-re van szükségünk.

Kérlek, hozd létre az index.html fájlt az alábbi tartalommal:

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-
scale=1">
<link rel="stylesheet" type="text/css" href="style.css">
<href="https://fonts.googleapis.com/css?family=Crimson+Text|
Julius+Sans+One" rel="stylesheet">
<title>Freedom</title>
</head>
<body>
<div class="wrapper">
<p class="quote">"The freedom of Mankind does not lie in the
fact that we can do what we want, but that we do not have to do that
which we do not want."</p>
<p class="author"><small>– Jean-Jacques Rousseau</small></p>
</div>
</body>
</html>

Ha kész vagy, mentsd el a fájlt, és mehetünk is tovább.

4.5. Kövesd el az első commitod

Az előző leckében sikeresen létrehoztad az első fájlodat a projektben. Ez egy
kiváló alkalom arra, hogy szinkronizáld a munkádat a GitHubon lévő távoli
repositoryval, és elmentsd az új verziót.

Ehhez a következő lépéseken kell végigmenned:

1. lépés: Készítsd elő a változtatásaidat

 1. Ha még nem tetted, akkor mentsd el a fájlodat és a változtatásaidat a
szövegszerkesztőben.
2. Válts át a parancssori kezelőfelületedre, és győződj meg róla, hogy a
projekt megfelelő mappájában vagy.

2. lépés: Ellenőrizd le a projekt státuszát

Gépeld be a parancssorba azt, hogy git status, és nyomj Entert. Egy ehhez
hasonló üzenetet kell visszakapnod:

$ git status
On branch main

No commits yet

Untracked files:
(use "git add <file>..." to include in what will be committed)
index.html

nothing added to commit but untracked files present (use "git add"
to track)

A git status parancs megmutatja neked a helyi repository aktuális állapotát a

távolihoz képest:

 Az első sor azt mondja neked, hogy a main (fő) ágon vagy. Ezt egyelőre
nyugodtan hagyd figyelmen kívül, majd később beszélünk a
leágazásokról.
 A második sor azt jelenti, hogy még nem követtél el egy commitot sem.
 Az „Untracked files:” (nem követett fájlok) rész megmutatja a helyi
változtatásaidat: létrehoztál egy fájlt. A Git azt is hozzáteszi, hogy ez a fájl
és a változtatásai még nincsen hozzáadva a commitodhoz.
o Ha itt az index.html fájlon kívül esetleg látsz más fájlokat is, az
azért lehet, mert az asztali kódszerkesztőd automatikusan
hozzáadta őket a projektedhez. Ezekkel a fájlokkal most nem kell
foglalkoznod.

Megjegyzés: Ha már lennének commitjaid, akkor a második sorban az alábbi

üzenetet látnád: Your branch is up-to-date with 'origin/main'. Ez annyit
jelent, hogy minden megvan nálad, ami a távoli repoban (a mesterverzióban)
megvolt az utolsó alkalommal, amikor lekérted.

Megjegyzés: Egy commit azoknak a változtatásoknak a gyűjteménye, amelyeket

fel szeretnél tölteni a távoli repositoryba.

Mielőtt hozzáadnánk a fájlt egy commithoz, jó, ha tudod, hogy a Git négy külön
szakaszban kezeli a fájljaidat:

1. Az első a working directory (munkakönyvtár) a saját gépeden (jelen

esetben a git-basics-project mappa). A munkakönyvtárban tudod
megváltoztatni a fájlokat.
2. Amikor készen állsz, át kell vinned a megváltoztatott fájlokat a staging
area nevű átmeneti területre. Ez egy elméleti állomás a munkakönyvtár
és a helyi repository között.
3. Amikor már minden a staging areában van, becsomagolhatod a
változtatásaidat egy commitba, átmozgatva őket a helyi repositoryba.
4. Ezután fel tudod tölteni (tolni, angolul: push) a változtatásaidat a távoli
repositoryba. A távoli repository az utolsó állomás a folyamatban.

3. lépés: Add hozzá a változtatásaidat a staging areához

A git add parancs segítségével adhatod hozzá a fájljaidat a staging areához.

Két módon járhatsz el:

 hozzáadhatsz fájlokat egyenként a git add your-file-

name.extension paranccsal (ahol a your-file-name a fájl neve,
a .extension pedig a kiterjesztése), vagy
 minden változást egyszerre hozzáadhatsz a git add --all paranccsal
(két kötőjel szerepel az all előtt).

Tipp: Valószínűleg a második opciót fogod használni többet, legalábbis a

közeljövőben.

Próbáld ki. Válts át a parancssori kezelőfelületedre, gépeld be a git add

index.html parancsot, és nyomj Entert. A projektmappában létrejövő esetleges
új fájlokat most nem akarjuk hozzáadni a staging areához, ezért nem a git add
--all parancsot használtuk.
Megjegyzés: Ezúttal nem fogsz választ kapni a parancssorban. Ez így van jól, ez
az elvárt viselkedés.

4. lépés: Hozz létre egy commitot

A fájljaid most már a staging areában vannak. Itt az ideje becsomagolni őket egy
commitba.

Gépeld be, hogy git commit -m "add index.html", és nyomj Entert. Ha

minden jól ment, válaszul kapsz egy üzenetet, amely részletezi a
módosításaidat: hány fájl változott meg, pontosan melyek stb. A változtatásaid
most már készen állnak a távoli repositoryba való feltöltésre.

Megjegyzés: Az idézőjelek közötti rész megnevezése commit message (commit

üzenet). Egy jó commit üzenet rövid, összefoglalja, hogy a commit milyen
változtatásokat hajt végre a repositoryban, és angol nyelvű. Figyelj oda arra,
hogy igényes commit üzeneteket írj – ez egy fontos szokás, ha szeretnél más
fejlesztőkkel együtt dolgozni.

5. lépés: Pusholj a távoli repositoryba

A Git nyelvezetében a változtatások feltöltését pusholásnak nevezzük. Ez jelenik

meg az ehhez használt parancsban is: git push.

Írd is be, hogy git push, majd nyomj egy Entert. A géped egy darabig dolgozni
fog, és végül ki fog írni valami ehhez hasonlót a parancssorba:

$ git push
Counting objects: 1, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (1/1), done.
Writing objects: 100% (1/1), 612 B | 251.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To https://github.com/your-username/git-basics-project.git
commit-number-1..commit-number-2 main -> main
$
Ha ezt látod, gratulálunk! A változtatásaid feltöltődtek a távoli repositoryba, és
az oldalad új verziója biztonságban el lett ott tárolva.

Tipp: Ha szeretnéd ezt leellenőrizni a másik oldalról, akkor keresd meg a

repositorydat a GitHubon. Amennyiben sikerrel jártál, itt megtalálod
az index.html fájlt. Ha megnyitod a „Commits” fület, láthatod a commit
üzenetedet és pár további infót is.

Az alábbiak közül melyik paranccsal tudod feltölteni a változtatásaidat a

távoli repositoryba?

git add
git commit -m "your-commit-message"
git push
git status
Ellenőrzöm a válaszom

Megy ez neked, ott a pont!

4.6. Mikor commitolj?

Gratulálunk még egyszer az első sikeres commitodhoz!

Gyorsan fussuk át újra a folyamatot, mert a jövőben remélhetőleg

számtalanszor fogod használni:

1. Dolgozz a kódon, hozz létre fájlokat, mappákat, változtass meg dolgokat.

Amikor elértél egy mérföldkövet, ments el mindent, és válts a CLI-odra.
2. Navigálj a projekted mappájába.
3. A git status paranccsal csekkold le a helyi repositoryd státuszát.
4. A git add --all beírásával add hozzá az összes változtatásodat a
staging areához.
5. Hozd létre a commitod a git commit -m "your-commit-
message" paranccsal. (Az idézőjelek közé jön a commit üzeneted.)
6. Használd a git push parancsot, hogy feltöltsd a változtatásaid a távoli
repositoryba.
7. Addig ismételd ezt a ciklust, amíg kész nem vagy.

Honnan tudod, hogy mikor van itt az ideje egy commitnak?

Nincsenek kőbe vésett szabályok arra nézve, hogy mikor commitolj. Különböző
iskolákból viszont van bőven, a két leggyakoribb:

 Commitolj, amikor készen vagy valamivel: ez azt támogatja, hogy csak

akkor commitolj, amikor elkészültél egy értelmezhető résszel a
projektedből (például egy komponenssel, aloldallal vagy új függvénnyel).
 Commitolj X percenként: eszerint pedig mindegy, mi van, commitolj X
(mondjuk 15) percenként.

Mindkét filozófiának van előnye és hátránya, követői és ellenzői. Döntsd el, hogy
neked melyik szimpatikusabb, és használd azt. Illetve sose felejtsd el
megkérdezni, hogy mi a szokás, ha új csapatba érkezel.

A lényeg, hogy ments, commitolj és pusholj rendszeres időközönként – a

részletek kevésbé számítanak.

Az alábbiak közül melyik paranccsal tudod megnézni, hogy mi a különbség

a kódod helyi változata és a távoli szerveren tárolt verzió között?

git add
git commit -m "your-commit-message"
git push
git status

5.1. A Git színterei

Az előző fejezet végére sikerült létrehoznod az első commitodat, majd ezt
commitot a git push parancs segítségével felküldted a távoli szerverre, frissítve
ezzel az ott lévő repositoryt.

Egész pontosan a következő parancsokat használtad fel:

 git add
 git commit
 git push

Ezek a parancsok mind egy-egy külön színtérre tolták át a változtatásaidat.

 Working directory - Munkakönyvtár

o Ez az a hely ahol a fájlok és mappák találhatóak. Ez egy verzióját
tartalmazza a projektnek.
 Staging area
o Ide kerülnek a git add parancsal hozzáadott módosított fájlok.
 Helyi repository
 o A módosított fájlok a staging areaból ide kerülnek a git
commit parancs segítségével. Ezzel már gyakorlatilag egy új verziója
készült el a projektnek, ami még egyenlőre a gépeden létezik.
 Távoli repository
o A helyi repositoryból ide fut ki a projekt egy verziója a git
push paranccsal, azaz a projekted egy új verziója már egy távoli
szerveren csücsül.

Ezek a színterek nem csak a mester példány frissítésében játszanak szerepet,

hanem akkor is, amikor gépeden található projektnél is. Ám ott már teljesen
más parancsokra lesz szükségünk.

Ebben a fejezetben megnézzük miként tudjuk az előző folyamatnak a fordítottját

végrehajtani.

5.2. Commitok importálása

A jövőben biztosan találkozhatsz majd olyan repositoryval, amelyen több
fejlesztővel dolgozol egyszerre. Így előfordulhat az is, hogy a te gépeden egy
sokkal régebbi verziója létezik a projektnek, míg a mesterverzió már jó pár
committal előrébb jár. Erre az lehet a megoldás, ha a gépeden található verziót
frissítjük a távoli verzióval.

Elsőként megnézzük miként tudunk előidézni változásokat GitHubon,

„szimulálva” egy másik fejlesztőt.

Commit létrehozása GitHubon

Első lépésként nyisd meg GitHubon a projektedet.

A commit során egy README fájlt fogunk hozzáadni a projekthez. Felmerülhet a
kérdés benned, hogy oké, de mi az a README fájl?

Ez egy olyan szöveges fájl, amelynek tartalma mindig a fájlok alatt fog
megjelenni. Olyan hasznos információkat szoktak beleírni, mint például, hogy
miről szól a projekt, vagy összetettebb program esetén egy futtatáshoz
szükséges lépéseket. Egy szóval ez egy rendkívül hasznos dokumentum, amely
majdnemhogy nélkülözhetetlen minden projektnél.

Kanyarodjunk vissza oda, hogy szeretnénk készíteni egy README fájlt. Ezt
legegyszerűbben az „Add a README” gombra teheted meg.

Miután megnyomtad a gombot a következő ablak fogad:

1. A Preview fület megnyitva egy gyors előnézetet kaphatsz a README fájlról.

2. Ide magát a README tartalmáz írhatod. A # után írd be a projekt címét.

Tipp: Amint látod ez a dokumentum egy kissé furcsa szintaxissal rendelkezik. Ez

egy úgynevezett Markdown fájl. A részletes működésébe most nem fogunk
belemenni, ám ha nagyon kíváncsi vagy, egy gyorstalpalót találhatsz ezen az
oldalon a legfontosabb szabályokból.

A commit végrehajtásához egy kicsit görgess le az oldalon.

 1. Írd be a megfelelő commit üzenetet.
2. A commit létrehozásához pedig nyomj a „Commit new file” gombra.

Ha megvagy, akkor már láthatod is a fájlok alatt azt, hogy milyen címet írtál be
a README fájlba.

Megjegyzés: Fontos! Mi a CodeBerrynél nem tartjuk jó gyakorlatnak azt, hogy

GitHub felületén hozz létre fájlokat, majd ott commitolj. Az egészet azért
csináltuk, hogy imitáljunk egy másik fél által készített commitot.

Commit letöltése

Most hogy kész az új commit, kocogj vissza a CLI-dbe. A commit letöltéséhez a

következő parancsot kell használd: git fetch.

Írd is be, hogy git fetch, majd nyomj egy Entert. A géped egy darabig dolgozni
fog, és végül ki fog írni valami ehhez hasonlót a parancssorba:

git fetch
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (2/2), done.
 remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
From https://github.com/your-username/your-project
fa0d3d4..76f4063 main -> origin/main

Ha ezt látod, gratulálunk! Sikeresen letöltötted a változtatásokat.

Megjegyzés: A git fetch parancssal nem csak egyetlen commitot töltöttünk le,
hanem az összes változást amely a távoli repositoryban történt. Tehát ha több
commit esetén az összeset letöltené.

Most nyisd meg a projektet egy asztali szerkesztőben. Hoppá! A README fájl
sehol sincs a projektben. Akkor most hogy is működik ez a git fetch?

Valójában a git fetch a távoli repositoryból csak a helyi repositoryba húzta le a

commitot, ezért nem látszódik még nekünk, hiszen nincs benne még a
munkakönyvtárunkba.

A következő leckébe megnézzük, hogy ezt az új verzót hogyan tudjuk beépíteni

a munkakönyvtáradba.

Hogy működik a git fetch parancs?

A git letölti a legutolsó commitot a munkakönyvtárba.
A git letölti a legutolsó commitot a helyi repositoryba.
A git letölti az összes commitot a munkakönyvtárba.
A git letölti az összes commitot a helyi repositoryba.
Ez igazán szép megoldás volt. Büszke lehetsz magadra!

5.3. Változtatások beolvasztása

Az előző leckében ott hagytuk abba, hogy a commit már a helyi repositoryba
került. Most már csak egy lépésre vagyunk a változtatások beolvasztásától a
munkakönyvtárunkba. Ahhoz, hogy ezt végre tudjuk hajtani meg kell nézzük,
hogy valójában hogyan került mentésre a commit a helyi repositoryba.

origin

A klónozás során a git rengeteg mindent beállított háttérben, többek között azt
is, hogy a projekt mappát honnan töltöttük le. Azaz a git tudja, hogy a
munkakönyvtárunk melyik GitHub projekthez kapcsolódik. Ennek a távoli
repositorynak adott is egy álnevet: origin. Ezt máris le is tudod ellenőrizni a CLI-
ben a git remote paranccsal.

Megjegyzés: A git remote parancshoz hozzáadott paraméterek segítségével

különböző információkat tudhatunk meg, illetve számos beállítást hajthatunk
végre a távoli repositoryn.

Sőt akár a pontos URL-t is le tudod kérni, ha a következőt írod be a CLI-be:

git remote -v
origin https://github.com/your-username/your-project.git
(fetch)
origin https://github.com/your-username/your-project.git (push)

Mindent összevetve az origin egy álnév a távoli repository URL-jére.

origin/main

Ezt a kifejezést már biztosan láthattad a git status parancs során.

git status
On branch main
Your branch is up-to-date with 'origin/main'.
Azt válaszolta nekünk a CLI, hogy a main ágon állunk, és hogy ez az ág
naprakész az origin/main ággal. Anélkül, hogy mélyen bele mennénk mit is
jelentenek a leágazások gitben annyit kell ebből tudni, hogy a távoli repositoryt
lekövethető az origin/main ággal.

A git fetch paranccsal lehúztuk a változásokat a helyi repositoryban

található origin/main ágra. Ahhoz, hogy ezeket a változásokat lássuk a
munkakönyvtárunkba is, a main ágat szinkronizálni kell a origin/main ággal.
Ebben fog segíteni nekünk a git merge parancs.

Megjegyzés: Elöljáróban a leágazásokról elég annyit tudnod, hogy úgy lehet

tekinteni rájuk, mint egy verziójára a projektnek. Fontos, hogy nem magát a
munkakönyvtáradat jelöli, hanem annak egy verzióját.

git merge

Ennek a parancsnak nagyon fontos alapköve az, hogy tudja milyen ágon áll
jelenleg, hiszen ide fogja beépíteni a változásokat. A git status során már
láthattuk, hogy jelenleg a main ágon vagyunk. Ez tökéletes, hiszen ide
szeretnénk beolvasztani a változásokat. A git merge parancsnak szüksége van
egy extra paraméterre, amely megmondja neki hogy mely ágról építse be a
változásokat.

Azt már tudjuk, hogy az origin/main ágon csücsülnek a helyi repositoryban a

változások, most már csak ennek a beolvasztása hiányzik.

git merge origin/main

Updating fa0d3d4..76f4063
Fast-forward
README.md | 1 +
1 file changed, 1 insertion(+)
create mode 100644 README.md

Szuper! Ha most megnyitod a kódszerkesztődet, akkor már láthatod az új fájlt a

projekt mappában.
Hogy működik a git merge parancs?
A paraméterben megadott ágról beolvasztja a változtatásokat az aktuális
ágba.
A paraméterben megadott ágról beolvasztja a változásokat a
munkakönyvtárba.
A paraméterben megadott ágról beolvasztja a változásokat a helyi
repositoryba.
A paraméterben megadott ágról beolvasztja a változásokat a main ágba.

Úgy bizony!

5.4. Commitok importálása és beolvasztása

Ennek az egész commit letöltése a helyi repositoryba, majd annak beolvasztása
egy ágra van egy rövidített változata is, mégpedig a git pull.

Tulajdonképpen a git pull a git fetch és git merge paracsokat hajtja végre
egymás után. Próbáljuk is ki!

Nyisd meg újra GitHubon a projektedet, és adj meg egy rövid leírást a projektről
a README fájlban. Ezt legegyszerűbben úgy tudod megtenni, hogy a kis ceruza
ikonra kattintasz:
Most egy ismerős felület töltött be, hajtsd végre a változtatásokat, majd készítsd
el egy új commitot. Ha kész vagy akkor csapd fel a CLI-t, és írd be a git
pull parancsot.

git pull
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
From https://github.com/your-username/your-project
76f4063..ef6e8a1 main -> origin/main
Updating 76f4063..ef6e8a1
Fast-forward
README.md | 2 ++
1 file changed, 2 insertions(+)
Hogy működik a git pull parancs?
A távoli repositoryból letölti a változtatásokat a munkakönyvtárba.

Helyes válasz. Piros pont jár érte!

A távoli repositoryból letölti a változtatásokat a helyi repositoryba, majd

beolvasztja azokat a munkakönyvtárba.

Helyes válasz. Piros pont jár érte!

A távoli repositoryból letölti a változtatásokat a helyi repositoryba.

A távoli repositoryból letölti a változásokat a staging areaba.

Ellenőrzöm a válaszom

Nagyon vágod a témát! Igen, eltaláltad az összes helyes választ.

6.1. A branchek rendszere

Korábban már találkoztunk a leágazás kifejezéssel, ezen belül is a main ágról
esett szó. De mi is ez a main és mit jelent egyáltalán egy ág a Git esetén?
Futtassuk le a git status parancsot.

git status
On branch main
Your branch is up-to-date with 'origin/main'.
A Git azt írja nekünk: On branch main

Megjegyzés: A branch magyarul ágat jelent, gondolj például egy fa ágára. Ha

Gitet használsz, akkor nagyon gyakran fogsz találkozni vele, főleg ha másokkal
dolgozol majd együtt.

A Gitet képzeld el úgy, mint egy fát. A main branch lesz a fa törzse, ez
mindennek az alapja. Eddig ezen dolgoztunk, nem hagytuk el fa törzsét. De ez
nem a legjobb módszer, ha már többen dolgozunk együtt ugyanazon a
kódbázison. Könnyen megtörténhet, hogy ketten ugyanazt a kódsort akarjuk
szerkeszteni.

Itt jön be a képbe a Git egyik legnagyobb erőssége, a branch.

Mi a tudunk tenni akkor, ha többen szerkesztenénk ugyanazt a sort a kódban?

A main branch mellett mi is létrehozhatunk branchet. Aztán az újonnan

létrehozott branchre bármikor átmehetünk, és ha változtatunk a kódon, akkor
az csak branchen történik és nincs hatással a main vagy bármely másik
branchre. Leggyakrabban egy új funkcionalitás hozzáadásakor használjuk,
például a branchen hozzáadunk egy új komponenst a weboldalunkhoz.

Amikor végeztünk a branchünkön, akkor az ott elvégzett változtatás

visszaépíthető a main branchbe. Ehhez egy már ismert Git parancsot fogunk
használni.

Következő lépésként megnézzük, hogyan tudunk létrehozni egy új branchet.

Előtte azonban válaszold meg az alábbi kérdést.

Mit jelent a branch a Gitben?

A branch a Git másik neve.

A branch a main ágat jelenti.
A branch egy Git fajta.
A branch a Git egy része, a kód egy „ága”.

Helyes válasz. Piros pont jár érte!

6.2. Egy új branch

Na de hogyan is tudunk létrehozni egy új branchet?
Menj vissza a gépeden létrehozott projektbe. Ha minden jól ment, akkor az
előző fejezetben beolvasztottad a README fájl változtatásait a gépeden lévő
fájlokba. Ebben a fejezetben csak a gépünkön fogunk dolgozni anélkül, hogy a
távoli repositoryba feltöltenénk a változásokat.

A biztonság kedvéért futtassuk le újra git status parancsot, hogy

megbizonyosodjunk arról, hogy jó helyen állunk:

git status
On branch main
Your branch is up-to-date with 'origin/main'.

Bash
Copy
Minden okés, éppen a main branchen állunk. Ha létre szeretnénk hozni egy új
branchet, akkor a git branch parancsot fogjuk használni. Ez a parancs egy
paramétert vár, ami a branch neve lesz. Hozzunk létre egy style nevű branchet:

git branch "style"

Bash
Copy
Megegyzés: Fontos, hogy a branch neve mindig kerüljön idézőjelek közé. Illetve
figyelj arra, hogy a név ne tartalmazzon szóközöket.

Ha minden jól ment, akkor nem fogsz látni semmit. A Git a háttérben létrehozta
az új branchet. Ha szeretnénk látni, milyen branchek vannak a helyi
repositoryban, akkor írjuk be a git branch parancsot, most paraméter nélkül:

git branch
main
style

Bash
Copy
Láthatod, hogy a main branch mellett ott van az újonnan
létrehozott style branch is. Ezt a branchet arra fogjuk használni, hogy
létrehozzuk a weboldalunk stílusát, mert egyelőre csak a HTML fájl létezik.

Egy fontos dolog! Amikor létrehoztuk a style branchet, akkor az a main branch
éppen aktuális állapotát vette alapul, azaz jelenleg a main és a style branchünk
megegyezik. Ha most valamit változtatnánk a main branchen, akkor az nem
lenne elérhető a style branchen..

Mit csinálhat a git branch parancs?

Kilistázza a brancheket.

Nagyon vágod a témát! Igen, ez a jó válasz.

Kirajzolja a brancheket.
Létrehoz egy branchet, ha paraméterként megadjuk neki a branch nevét.

Nagyon vágod a témát! Igen, ez a jó válasz.

Hibát kapunk.

Ellenőrzöm a válaszom

Úgy-úgy, ami jó, az nem rossz, szép munka!

6.3. Másik branchre váltás

Létrehoztuk a style branchet, viszont egyelőre még csak a main branchen
állunk. Ugorjunk is át az új branchre és készítsük el a változtatásainkat.

A branchek közti váltáshoz egy új Git paranccsal fogunk megismerkedni, ez

a checkout lesz.

Írjuk be a CLI-be:

git checkout style

Switched to branch 'style'

Bash
Copy
Ennyi az egész, mostantól a style branchen vagyunk és azon dolgozunk.

Megjegyzés: A branch létrehozását össze is tudjuk kapcsolni a branch váltással.

Ha a git checkout parancsnak adunk egy -b paramétert és egy branch nevet,
akkor a Git létrehozza a branchet azon a néven és egyből át is vált ra. Például
a style branch esetén: git checkout -b "style".
Hogyan lehet branchet váltani?

git checkout branch-name

Abszolút így van. Gratulálunk!

git branch branch-name

git branch -b "branch-name"

Abszolút így van. Gratulálunk!

git checkout -branch-name

Ellenőrzöm a válaszom

Megy ez neked, ott a pont!

6.4. Branchek egyesítése

Ideje kihasználnunk a létrehozott branchet. A style branchen fogjuk létrehozni
a weboldal stílusát.

Add hozzá a projekthez style.css fájlt az alábbi tartalommal:

html,
body {
margin: 0;
padding: 0;
font-size: 100%;
line-height: 1.5;
}
body {
width: 100%;
height: 100vh;
background: url('assets/freedom.jpg') no-repeat center;
background-size: cover;
color: #333;
}
.wrapper {
padding-top: 4rem;
width: 90%;
margin: 0 auto;
text-align: center;
}
.quote {
font-family: 'Julius Sans One', sans-serif;
font-size: 2.5rem;
}
.author {
font-family: 'Crimson Text', serif;
font-size: 1.5rem;
font-style: italic;
}

CSS
Copy
Ha kész vagy, akkor készíts egy commitot a változtatásokról.

Tipp: Nyugodtan menj vissza a korábbi leckékhez, ha még nem vagy teljesen
magabiztos a Git parancsokkal és folyamatokkal.

Változtatások hozzáadása a main branchhez

Készen vagyunk a funkcionalitással, de ez egyelőre még csak a style branchen

létezik. Valahogy be kell építenünk a main branchbe. Ehhez egy már ismert Git
parancsot fogunk használni: git merge.

Előzőleg a merge parancsot a távoli repositoryban található változtatások

beolvasztására használtuk. Akkor is egy branchből egy másikba vittünk át
változtatásokat. Most is ezt fogjuk tenni. Első lépésként váltsunk vissza
a main branchre:

git checkout main

Switched to branch 'main'

Bash
Copy
Ha ez meg van, akkor pedig használjuk a merge parancsot és a paraméterként
adjuk meg style branchet.

git merge style

Updating 7f6ec58..6121bea
Fast-forward
style.css | 33 +++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
create mode 100644 style.css

Bash
Copy
Ha visszamész a kódszerkesztőbe, akkor láthatod, hogy már a css fájl ott van a
projektben. Gratulálok!

Készítettünk egy új branchet login-page névvel és ezt a változtatást

szeretnénk beolvasztani a main branchbe. Milyen lépéseket kell
elvégeznünk hozzá?
A login-page branchen a következő parancsot kell futtatni: git merge main.
A main branchen a következő parancsot kell futtatni: git merge login-page.
A login-page branchen a következő parancsot kell futtani: git merge
origin/main.
A main branchen a következő parancsot kell futtatni:git branch –merge
login-page.

Ellenőrzöm a válaszom

Igen, igen, és megint csak igen. Ez a helyes válasz!

6.5. Branch törlése

És kész is a funkcionalitás, amit meg akartunk valósítani. Megcsináltuk
a style branchet, ahol aztán hozzáadtuk a css fájlt a projekthez. Majd pedig a
változtatást beépítettük a main branchbe is. Egyetlen lépés van még hátra, a
felesleges branch törlése.

A style branch elérte célját, ezért nyugodtan kitörölhetjük. Ebben ismét a git
branch parancsot fogjuk használni, egy másik paraméterrel. Ez a paraméter -
d lesz. Töröljük ki a style branchet:
git branch -d style
Deleted branch style (was 61a6e5c2c).

Bash
Copy
Ennyi az egész. Ha lefuttatod a git branch parancsot, akkor már csak
a main branchet fogja kiírni.

Megjegyzés: Figyelj arra, hogy éppen melyik branchen állsz a törléskor. A Git
nem fogja engedni, hogy töröld azt a branchet, ahol éppen állsz. Ebben az
esetben át kell váltanod egy másik branchre.

Előfordulhat, hogy egy hibát kapsz a branch törlésekor, például egy ilyen
üzenetet:

git branch -d style

error: The branch 'style' is not fully merged.
If you are sure you want to delete it, run 'git branch -D style'.

Bash
Copy
Ezt a hibát akkor írja ki a Git, ha olyan módosítás van a törölni kívánt branchen,
amely még nem lett beolvasztva. Ezzel próbál megvédeni a Git. Ugyanis ha
kitörlöd a branchet, akkor az ott elvégzett változtatások elvesznek. Ha biztos
vagy a törlésbe, akkor írd be a Git által felkínált git branch -D
style parancsot.

Mielőtt ezt a parancsod használnád, győződj meg róla, hogy biztosan

törölni szeretnéd az adott branchet.

Az új funkcionalitás készen van, azonban egyelőre még csak a gépünkön létezik.

Hogy megjelenjen a távoli repositoryban is, használd a már ismert git
push parancsot.

Melyik paranccsal lehet törölni egy branchet?

git merge branch-name

git branch -d branch-name
Watson, Önnek teljesen igaza van!

git branch branch-name

git branch -D branch-name

Watson, Önnek teljesen igaza van!

Ellenőrzöm a válaszom
Helyes válasz. Piros pont jár érte!
7.1. Hogyan dolgozzunk együtt GitHubon?
Tanuló programozóként, amíg egyedül haladsz az anyagok gyakorlásával,
könnyen tudod menedzselni a kódodat a Giten keresztül, hiszen csak te
változtatsz a saját projektjeid tartalmán. Amikor viszont egyre tapasztaltabbá
válsz, és elkezdesz összetettebb feladatokon dolgozni, nagyrészt másokkal
közösen teszed majd ezt, legyen szó akár munkáról, akár csak egy hobby
fejlesztésről.

A közös munka járhat előnyökkel és hátrányokkal is. Mivel mind ugyanazon a

kódbázison dolgoztok, ez könnyen konfliktusokat eredményezhet. Ha valaki
véletlenül hibás kódot tölt fel a távoli repositoryba, és beolvasztja azt
a main branchre, akkor felülírja vele a fent lévő kódot, amivel eltörheti a
program működését.

Szerencsére, a közös munka egyik legnagyobb előnye, hogy tudjátok ellenőrizni

is egymást, és így nagyban csökkenthető a fenti konfliktusok kialakulásának
esélye. Ugyanis, mielőtt valami kimegy a main branchre, vissza lehet jelezni még
a korai fázisban, ha a kód nem működik megfelelően, és javítást igényel.

Ebben a fejezetben azt fogjuk bemutatni, hogy ezt az ellenőrzést hogyan lehet a
Gitben végrehajtani. Lássunk is neki!

7.2. Adjunk háttérképet a honlaphoz

Először is ahhoz, hogy teljes legyen a projektünk, szükségünk van még egy
háttérképre a honlapunkon. Ezt egy új, assets nevű branchen adjuk hozzá,
amelyet a main-ből ágaztassunk le. Amikor kész az új branch, hozzunk létre a
projekt könyvtárában egy új mappát, amelyet szintén hívjunk assets-nek.
Megjegyzés: Érdemes észben tartanod, hogy a Git figyelmen kívül hagyja
azokat a mappákat, amelyek nem tartalmaznak fájlt, azaz ha az assets mappád
üres lenne, a git status parancs nem jelenítené meg.

Az assets mappa fogja tartalmazni a háttérképet, úgyhogy gyorsan szedjük is le

a fájlt innen, és helyezzük el az újonnan elkészült mappánkban.

Ha ezzel megvagy, akkor:

1. Add hozzá a fájlt és a mappát a projekthez (git add).

2. Írd meg egy üzenetben min változtattál (git commit).
3. Küldd fel a távoli repositoryba a változtatásokat (git push).

És akkor itt álljunk meg egy pillanatra. Ha mindent jól csináltál, az alábbi
üzenetet kaptad a CLI-ben:

$ git push
fatal: The current branch assets has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin assets

Bash
Copy
Ez azért történt, mert eddig csak a main branchet használtad a távoli
repositoryban, az assets branch egyelőre csak a helyi repositoryban létezik.

Írd be a git által felkínált parancsot: git push --set-upstream origin assets,
ez hozza létre ugyanis az új branchet a távoli repositoryban, ahova egyúttal
feltölti a változtatásokat.

Ezt könnyen ellenőrizheted, ugyanis ha lenyitod a GitHub branch választó fülét a

pusholás után, ott látszik az új branch:
Ha itt kiválasztod az assets branchet, láthatod azt is, hogy a fájlok listája is
kibővült az assets mappával:

Tipp: Ha egy mappa tartalmát szeretnéd megnézni GitHubon, akkor kattints a

mappára, és a böngésző elnavigál a benne található fájlokhoz.

7.3. Pull request készítése

Ahhoz, hogy ellenőrizhessük egymás munkáját, szükség van egy olyan állapotra
a Git munkafolyamatban, amikor a változtatások a saját branchünkön készen
vannak, de még nem jelentek meg azon a branchen, ahol élesíteni szeretnénk
őket.

Amikor ez az állapot fennáll, létre hozhatunk egy úgynevezett pull request nevű
folyamatot, amelyen keresztül ellenőrizhető a munkánk. Ebben a leckében egy
pull request elkészítésén megyünk végig a GitHub segítségével.

Megjegyzés: Amikor változtatunk valamit a kódon, azt mindig pull requesten

keresztül vezessük vissza az eredeti branchre, ne olvasszuk be anélkül, hogy
valaki ne ellenőrizte volna le.

Megjegyzés: A pull request kifejezésnek nincs magyar megfelelője, mindenki

angolul használja.

A pull request kezelőfelület

Első lépésként kérlek, kattints az oldal tetején található „Pull requests”

menüpontra:
Ezzel átkerültél a GitHub pull requesteket kezelő felületére:

Mi az a pull request?

Egy olyan része a git munkafolyamatnak, amikor valaki megkér minket, hogy
a git pull paranccsal húzzuk le a változtatásokat a távoli repositoryból.
Egy olyan része a git munkafolyamatnak, amikor valaki megkér minket, hogy
küldjük el a változtatásokat a távoli repositoryba.
Egy olyan része a git munkafolyamatnak, amin keresztül valaki ellenőrizni
tudja a saját branchünkön végrehajtott változtatásokat, mielőtt azokat
beolvasztjuk az éles branchre.
Egy olyan része a git munkafolyamatnak, amin keresztül valaki ellenőrizni
tudja, hogy milyen változtatásokat olvasztottunk már be az éles branchre.
Ellenőrzöm a válaszom

Ez igazán szép megoldás volt. Büszke lehetsz magadra!

7.4. Pull request kezelése

Most, hogy készen van az első pull requested, megmutatjuk hogyan működik a
másik oldal, azaz amikor valaki ellenőrzi a beküldött pull requestet. Az
egyszerűség kedvéért, most a saját magad által beküldött változtatásokat fogod
ellenőrizni.

Megjegyzés: Éles környezetben csak akkor javasoljuk, hogy ne valaki más

ellenőrizze le a pull requestedet, ha valami nagyon kicsi változtatás történik, és a
csapatod által előre lefektetett munkafolyamat kitér arra, hogy nyugodtan
elfogadhatod magadnak is. Minden más esetben az a bevett gyakorlat, hogy
valaki más ellenőrizze le a változtatásokat, és tudjon neked visszajelzést
adni, ha valahol még javítani kell rajta.

A beküldött pull request

Amikor elkészült egy pull request, akkor a GitHubon az alábbi felület fogad:
Ami nekünk innen fontos:

1. A fenti menüsorban a „Pull requests” mögött megjelent egy szám. Ez a

jelenleg nyitott pull requestek számát mutatja repositoryban.
2. Itt láthatod a pull request nevét.
3. Itt azt írja, hogy a pull request nyitott, azaz még nem került beolvasztásra,
valamint, hogy mennyi commitot szeretnél beolvasztani.
4. Itt láthatod a pull request részletes leírását.
5. Itt láthatod a commitokat amiket szeretnél ellenőriztetni.
6. Itt tudod beállítani azokat, akiket szeretnél megkérni, hogy ellenőrizzék a
változásokat. Jelenleg ez te leszel, így nem kell külön beállítani.

Kicsit lejjebb görgetve még ezeket láthatod:

1. Itt jelzi a GitHub, hogy a beolvasztás elvégezhető.

2. A „Merge pull request” gombra kattintva tudod elindítani a pull request
beolvasztását a „base” branchre (jelen esetben ez a main).

Ha mindent rendben találsz, kattints a „Merge pull request” gombra. Ennek

hatására a felület az alábbi módon változik meg:
Ezen a ponton még egyszer, utoljára átgondolhatod, hogy rendben találsz-e
mindent. Ha igen, a „Confirm merge”-re kattintva véglegesíteni tudod a pull
request lezárását. Ha valamin mégis változtatnál, akkor „Cancel” gombra
kattintva visszaléphetsz.

A lezárt pull request

Ha lezártad a pull requestet, utána ez a képernyő fogad:

1. Itt az állapot „Merged”-re változott „Open”-ről, és a leírás is azt írja már,

hogy mennyi commitot olvasztottál be egyik branchből a másikba.
2. Itt megjelent egy sor, amely szintén azt írja, hogy melyik commitot
olvasztottad be a main-be.
3. Ez a doboz pedig azt mondja, hogy a pull request sikeresen be lett
olvasztva és lezárva. Felajánlja egyúttal, hogy a „Delete branch” gombra
kattintva biztonsággal törölhetjük az assets branchet, hiszen a
változtatások immáron megtalálhatók a main branchen is.

Töröld a branchet, majd a fenti a menüsorban kattints a „Code”-ra. Láthatod,

hogy a fájlok között megjelent az assets mappa, tehát mindent jól csináltál:

Megjegyzés: Egy pull requestet akkor zárjunk csak le, amikor a fejlesztéshez
kapcsolódó változtatásokkal végeztünk. Amíg ez nem történik meg, addig
commitokkal jelezzük a kisebb változtatásokat. Ha azt a visszajelzést kapjuk egy
ellenőrzés után, hogy még változtatni kell valamin, akkor tudunk még újabb
commitokat készíteni. Ezek pusholás után automatikusan megjelennek a pull
requestben. Mindig figyelj oda, hogy addig ne legyen lezárva egy pull
request, amíg az összes commitot át nem nézte valaki.

Itt az alábbi részek lesznek nekünk fontosak:

1. A „New pull request” (új pull request) gombbal tudsz új pull requesteket
létrehozni.
2. Ha vannak már nyitott, átnézésre váró pull requestek a repositoryban,
azokat ezen a részen találhatod meg. Mivel még nem hoztunk ilyet létre,
ez a terület jelenleg üres.

Kattints a „New pull request” gombra.

A branchek beállítása

Második lépésként az alábbi felületre érkeztél meg:

Itt tudod beállítani, hogy melyik brancheket szeretnéd összevetni egymással.

Ezzel többek között azt is beállítjuk, hogy mely brancheket szerenténk
összefűzni. A brancheket az alábbiak szerint állítsd be:

1. A „base” legyen az a branch, ahova be akarod olvasztani a változtatásokat.

2. A „compare” legyen az a branch, ahol csináltad a változtatásokat.
3. A mi esetünkben utóbbi az assets lesz, válaszd ki a lenyíló listából.

Amikor kész vagy a fenti beállításokkal, az alábbi módon változik a felület:

Itt ezeket láthatod:

1. Egy rövid ellenőrzés után a GitHub kiírja, hogy „Able to merge.” Ez annyit
jelent, hogy az assets branch változásait be tudjuk majd olvasztani
a main-be.
2. Alul megjelennek egymás alatt a commitok, és azok tartalmai, benne a
változtatásokkal. Jelenleg csak egy commitot pusholtunk fel a távoli
repositoryba, de ha lenne több, akkor itt találnád egymás alatt őket.
3. A pull request létrehozásához kattints a „Create pull request” gombra.

A pull request neve és leírása

Utolsó lépésként egy olyan oldalra kerülsz, ahol megadhatsz még néhány
beállítást a pull requestnek:

1. Itt tudod elnevezni a pull requestet. Célszerű olyan nevet adni, amely
röviden és egyértelműen, pár szóban összefoglalja az elvégzett
változtatásokat.
2. Itt tudsz hosszabban írni arról, hogy miről szól az adott pull request.
Továbbá, ha valami speciális kérésed van a kód ellenőrzője felé, szintén itt
tudod ezt megfogalmazni számára.

Amint ezeket is beállítottad, kattints a „Create pull request” gombra. És ezzel

készen is vagyunk, megszületett az első pull requested!

Mikor lesznek a „compare” branchen végzett változtatások elérhetők a

„base” branchen?
 Miután a pull requestet lezártuk.
A pull request elkészültekor.
Az utolsó commit elkészültekor.
Amikor a GitHub ellenőrizte, hogy nincsen konfliktus a két branch között.

Úgy bizony!

8.1. Publikáld a munkád a GitHub Pages

segítségével
A GitHub nem csak a projektek verziókezelését támogatja, hanem a számos más
szolgáltatással bír. Ezekből számunkra most a legérdekesebb a GitHub Pages
lesz.

Segítségével képesek leszünk publikálni az elkészült oldalunkat!

Ha valahol elakadtál volna, és nem sikerült befejezni az oldalad, akkor nézd meg
a mi példamegoldásunkat ebben a repositoryban, és használd fel a saját
munkádhoz.

Hogyan működik a GitHub Pages?

A weboldalak publikálása régebben kifejezetten nehéz volt. Először is venned

kellett tárhelyet egy cégtől, aztán egy domainnevet egy másiktól, összekötni a
kettőt, majd feltölteni a fájljaidat és mappáidat FTP-n keresztül, végül pedig még
be is kellett állítanod egy csomó dolgot egy kevéssé felhasználóbarát
adminfelületről.

Ehhez képest a GitHub Pages mágiának tűnik. Tényleg csak néhány kattintásba
kerül közzétenni a weboldaladat. Mutatom, hogyan:
  Nyisd meg a repositoryd GitHubon (jelen esetben a git-basics-
project repositoryt).
 Kattints a „Settings” (beállítások) fülre.

1. Görgess le a „GitHub Pages” szekcióhoz.

2. A „Sources” résznél válaszd ki a main ágat, és a /(root) mappát, majd nyomj
a „Save” gombra.

Az oldal újra fog töltődni, és a „GitHub Pages” szekció tetejénél meg fog jelenni
egy zöld sáv, benne egy üzenettel, miszerint a weboldalad publikálva lett a
megadott webcímen: Your site is published at https://your-username.github.io/repository-
name/, melyben a your-username a saját felhasználóneved, a repository-name pedig a
repositoryd neve.

Megjegyzés: Ne aggódj, ha eleinte azt látod, hogy a weboldalad még csak

készen áll a publikálásra: Your site is ready to be published at https://your-
username.github.io/repository-name/. Beletelhet egy kis időbe, míg a GitHub
közzéteszi a weboldaladat. Várj pár percet, aztán frissítsd az oldalt.

A link a weboldaladra mutat, és nyilvános. Nyugodtan küldd el a barátaidnak

vagy anyukádnak, hogy megmutasd, mit építettél.

Mondtam, tiszta mágia.

Néhány figyelmeztetés

Habár a GitHub Pages elég király, vannak korlátai:

 Nem tudsz webalkalmazásokat publikálni rajta, mert nem képes

adatbázisokat hosztolni.
 Nem publikálhatsz rajta bármit. Bizonyos típusú tartalmakat nem
engedélyeznek a GitHub felhasználási feltételei.
  A Github Pages alapesetben mindig az index.html fájlt keresi és ebből
készíti el az oldalad. Ha nincs ilyen nevű fájlod, vagy másként nevezted el
a html fájlod, akkor sajnos nem fog működni.

Noha nem a GitHub Pages a megfelelő hely a webshopod elindításához, arra

tökéletes, hogy közzétedd a tanulós projektjeidet, a személyes weboldaladat,
blogodat, vagy akár komplexebb weboldalakat is a cégedhez, termékedhez vagy
szolgáltatásodhoz.

Pro Tipp: Ha szeretnél, tudsz használni saját domaint is a GitHub Pages-zel

publikált oldaladhoz. A látogatóid nem tudják majd megmondani, hogy egy
GitHub által hosztolt weboldalt néznek éppen, olyan lesz, mint bármely más
profi oldal a világon. A Domain regisztrációja és használata című modulunkban
többet is megtudhatsz majd erről a témáról. Ha most érdekelne, itt egy részletes
útmutató (angolul).

Feladat:
Másold ide a publikált oldalad linkjét.

A megoldásod:

https://vargaszilvia.github.io/git-basic-project/

9.1. Itt a vége

Ez itt a vége a "Tanuld meg az alap Git-munkamenetet" című modulunknak.

A modul során megtanulhattad:

 mi is az a Git és a GitHub, és mire használjuk őket,

 hogyan lehet a mappák és fájlok között navigálni parancssorból,
 hogyan kell beállítani a Git környezetet,
 mi az a repository, és hogyan lehet létrehozni,
 hogyan kell hozzáadni a változtatásaidat a távoli repositoryhoz a
parancssor segítségével,
 hogyan tudod a távoli repositoryban történt változásokat letölteni,
 mire jók a branchek, és hogyan kell velük dolgozni,
 miként lehet létrehozni, és beolvasztani egy pull requestet, valamint
 hogyan publikálhatod az oldaladat a GitHub segítségével.

Az elkészült projekt során pedig a következő Git parancsokat ismerted meg:

 git clone [projekt url]

 o Projekt letöltése a távoli repositoryból.
 git status
o Munkakönyvtár aktuális állapotának kinyomtatása. Megmutatja,
hogy a módosított fájlok éppen melyik színteren helyezkednek el.
Illetve, hogy készült-e commit.
 git add [fájl név] / git add .
o Módosított fájlok hozzáadása a staging areahoz.
 git commit -m [üzenet]
o A staging areaban található fájlok áthelyezése a helyi repositoryba.
 git push
o Commit feltöltése a távoli repositoryba.
 git fetch
o Commitok letöltése a távoli repositoryból.
 git merge [branch neve]
o Kettő branch egybeolvasztása.
 git pull
o Commitok letöltése és beolvasztása a munkakönyvtárba.
 git branch [leágazás neve]
o Új leágazás létrehozása.
 git checkout
o Váltás másik leágazásra.

Gratula, ezzel megtanultad használni az egyik legfontosabb szerszámot a

fejlesztői eszköztárból.