Másfél éve kszk-zom, leginkább a sysadminban találhattok meg, nemrég lettem megválasztva a kubernetesünk rendszergazdájának. A git-et már jó pár éve használom aktívan, el se tudom képzelni, hogy ne használjam egy projekthez.
Ebben a videóban szeretném nektek a git gyakorlati alkalmazását megmutatni, abba bevezetni titeket.
Kezdetben szeretnélek megkérni, hogy telepítsétek fel a git-et a gépetekre a segédletben leírtak szerint, vagy használjátok a linuxos előadáshoz kapott vm-eteket.
Én alapból zsh-t használok a gépemen, így lehet, pár dolog nem ugyanúgy fog kinézni, mint nálatok (ha bash-t használtok), de minden ugyanúgy működik (ez egy POSIX shell), csak kicsit barátságosabban néz ki 😉.
## Konfiguráció
Állítsuk be magunknak a git-et, hogy kényelmesen tudjuk használni.
Ezután állítsuk be, hogy a git milyen szövegszerkesztőt nyisson meg alapértelmezetten, ezt főként `commit`-oknál és `merge`-eknél fogjuk használni.
A szükséges parancs pedig:
```
git config --global core.editor vim
```
Én szeretek `vim`-et használni, de ti nyugodtan beállíthattok magatoknak `nano`-t, vagy akár a VS Code-ot is, sokszor elég kényelmes tud lenni.
Esetleg windows-on a notepad++-t is beállíthatjátok, ehhez a parancsot a segédleteben láthatjátok.
### Jelenlegi konfig
Nah, akkor nézzük meg, eddig mit alkottunk, hogy néz ki az összes git-es beállításunk:
Ezt a:
```
git config --list
```
parancs kiadásával nézhetjük meg.
## Alapok
Ha elakadtok git használat közben, akkor rengeteg segítség létezik, szerencsére a git-nek van egy nagyon jó help parancsa, valamint a man page-t is lehet nézegetni.
### Git repo
A git repository, vagy repo egy olyan mappa, mely gites verziókövetve van, azaz bárhol, ahol találunk egy .git mappát, az valójában egy git repo.
Kezdjünk is bele, készítsünk egy saját repot!
Ehhez készítsünk egy tetszőleges mappát, ez lesz a projektünk mappája, és lépjünk is bele.
```
mkdir projektem
cd projektem
```
Persze megnézhetjük, mi a helyzet a git-el, a `git status` paranccsal, de nem fog meglepni minket, hogy semmi (hiszen most hoztuk csak létre a projektet).
```
git status
hiba hiba....
```
A teljesen üres mappánk még nincs verziókezelés alatt. Egy `ls -la`-val ezt ellenőrizni is tudjuk, nem látunk `.git` mappát.
```
ls -la
```
#### Git init
Inicializáljuk hát ebbe a mappába a gitet, ezt a beszédes `git init` paranccsal tehetjük meg. Ez beállítja nekünk a `master` branchet és még jó pár alap dolgot (a branch-ről majd később beszélek még, egyelőre annyit elég tudni, hogy ide kerülnek a mentéspontok sorban, mint egy fa ága, innét jön a branch elnevezés).
```
git init
```
Ha megint megnézzük az `ls -la` paranccsal, mostmár van egy `.git` mappánk. Ebben benne van minden adatunk a repoval kapcsolatban.
Amikor egy távoli repo-t leszedünk, akkor ezt a `.git` mappát kapjuk meg, és ennek tartalmából már a gépünkön található git alkalmazás előállítja nekünk a master ág legutóbbi mentéspontját.
#### Mentéseink tárolása
A mentések tárolásának fajtáiról a jegyzetben olvashattok, itt annyit említenék csak meg, hogy a git minden, azaz tényleg minden fájlt lemásol, ami verziókezelés alatt áll. Azaz, ha feltöltünk egy 1 GiB-os videót, majd a következő mentéskor átnevezem a videót, akkor már 2 GiB-nyi videót fog tartalmazni a repónk. Ha ez megijesztett minket és megpróbálnánk letörölni, ettől még a repóban ugyanúgy benne lesz, méretet nem csökentünk vele, persze utólag vissza tudunk menni az adott mentéshez, és kitörölni belőle...
Nézzül meg, mi a helyzet a jelenlegi repónkkal.
```
git status
```
Láthatjuk, hogy még nincs semmilyen mentéspontunk, nincs mit elmentenünk. Megfigyelhetjük, hogy a git próbál segíteni nekünk (ezt jó sok helyen láthatjuk majd).
Vegyünk fel egy új fájlt:
```
echo alma > gyumolcskosar
```
Újra megnézve a git status-t, láthatjuk, megjelent a fájlunk, de még nincs verziókezelés alatt.
#### Git status-ok
Milyen állapotok léteznek egy repo-ban?
Van az:
- Untracked: Ami még nincs verziókontroll alatt
- Staged: Ami már verziókontroll alatt van de még nem
készítettünk róla pillanatképet
- Unmodified: Amit már elmentettünk és azóta nem változott
- Modified: Az a fájl, ami már verziókontroll alatt van
és változott. Ezt utánna szintén Stage-be tudjuk tenni
Láthatjuk, hogy a git megint próbál segíteni nekünk, írja is, hogy ahhoz hogy verziókövetve legyen a fájlunk, használjuk a `git add` parancsot.
Adjuk is ki:
```
git add gyumolcskosar
```
Itt a gyümölcskosár helyett írhattam volna simán . -ot, akkor a repo-ban található összes fájlt bele tette volna (kivéve persze, amit megtíltunk neki, erről is kicsit később).
Mostmár, ha `git status`-t hívunk, megjelenik a gyümölcskosarunk, új fájlként, `staged` állapotba került, akár el is tudjuk menteni. A mentéshez a `git commit` parancsot adjuk ki. Ekkor megnyílik az előre beállított szövegszerkesztőnk, valamint némi információ a leendő mentéspontról.
```
git commit
```
Láthatjuk, amit a `git status` írna ki, valamint pár segítséget a git-től.
A #-el kezdődő sorok kommentek, ezek a commit üzenetbe nem kerülnek bele, ezek csak nekünk szólnak.
Írjuk is be az első sorba, hogy Készítettem egy gyümölcskosarat, majd mentsük el a fájlt, zárjuk b e a szövegszerkesztőt.
A git érzékelte, hogy bezártuk a fájlt, abból kiolvasta a # nélküli sorokat és hozzáadta a mentéspontunkhoz, mint üzenet, valamint megjelent pár *hasznos* infó is.
Nézzük, most mi a helyzet a repoban?
```
git status
```
Már nem szól semmit amiatt, hogy nincs mentésünk (hiszen az előbb készítettünk egyet), továbbá azt is írja, hogy nincs semmi amin változtattunk volna, azaz erről az állapotról nem is tudnánk új mentést készíteni (megegyezne az korábbival).
Nézzük meg a következő két állapotot is, amiben egy fájl lehet. Írjuk bele a gyümölcskosarunkba, hogy már körte is van benne.
```
echo körte >> gyumolcskosar
```
Adjuk ki a `git status`-t:
Láthatjuk, hogy mostmár `modified` állapotba került a gyümölcskosarunk. Mentsük is el, de egy kicsit kényelmesebb módon.
```
git add gyumolcskosar
git commit -m "Raktam bele körtét is"
```
Fontos, ne felejtsük el először hozzáadni a fájlunkat a stage-hez, a `git add gyumolcskosar` paranccsal.
Készítsünk egy új fájlt `hordo` névvel, és nézzük meg, mit ír ki a `git status -s` parancs. Ezzel a kapcsolóval képesek vagyunk egy rövidített státuszt lekérni.
Add-oljuk, majd commit-oljuk el.
```
git add hordo
git status -s
git commit -m "Hoztunk egy hordót"
```
#### Gitignore
Oké, de mi van, ha nagyon nem szeretnénk, ha egy fájlunk verziókezelés alatt állna? Mondjuk a build-ek mappái, egy IDE által generált fájlokra, esetleg a gites előadás jegyzeteimre.
Hozzunk létre egy `jegyzeteim.txt`-t és egy `.gitgnore`-t
```
touch jegyzeteim.txt
touxh .gitgnore
```
Ha kiadjuk a `git status` parancsot, megjelenik a jegyzeteim.
Írjuk bele a a jegyzeteim.txt-t a gitignore-ba.
```
echo jegyzeteim.txt >> .gitignore
```
Adjuk ki *megint* a `git status` parancsot. Oh, eltűnt a jegyzetünk! Pont ezt akartuk, mostmár a git nem fogja figyelni ezt a fájlt.
A git nem tárol semmi adatot változásokról, csak mentéseket készít. Próbáljuk ki, mi történik, ha átnevezünk egy fájlt?
```
mv gyumolcskosar gyumolcskosar.txt
```
Toljunk egy `git status`-t.
Láthatjuk, hogy az eredeti fájlt "töröltük", és sikeresen létrehoztunk egy új fájlt a repoban. Nézzük meg, mi történik, ha add-oljuk a változtatásokat.
```
git add .
git status
```
Persze a szokásos `git status` sem maradhat el. Mostmár látszik, hogy átnevezés történt.##
A git képes rá, hogy felismerjea fájlokat és eldöntse, hogy a két fájl ugyanaz, csak átneveztük, mozgattuk, etc.. Követni nem tudja, csak azt látja, hogy létrejött egy új fájl, mint ami törölve lett nemrég.
#### Mentési előzmények
A git egyik leghasznosabb parancsa a `git status` után a `git log`.
Próbáljuk is ki:
```
git log
```
Láthatjuk, milyen mentéspontjaink vannak, és a hozzájuk tartozó dolgokat, mint a commit hash vagy az üzenet.
Picit szebbé is tehetjük, ha kiadjuk a parancsot a `--oneline` kapcsolóval.
```
git log --oneline
```
Máris csak a lényeget látjuk. Azt is észre vehetjük, csak 7 karaktert kapunk a hash-ből. ELég csak pár karakter, hogy be tudjuk azonosítani a commit-ot.
## Branch-ek, elágazás
### Mik azok a branch-ek?
Korábban már említettem a branch-et, mint fogalmat. Képzeljük el a git-et, hogy szeretne adatokat, mutatókat tárolni. Mi van akkor, ha egy mutatóból kétfelé is elindulunk? Mondjuk Rick és én elkezdünk együtt kódolni...
Képzeljük el úgy, mint egy fa törzse, melyből ágak jönnek létre. Készítünk egy ágat Rick-nek és egyet nekem. Így tudunk ketten külön dolgozni, míg a master-t nem piszkáltuk.
Úgy is el lehet képzelni egy nagyobb projektnél, hogy van a master, amin az éles, jól működő kód van, és van a fejlesztési ág, amin pedig a fejlesztők dolgoznak (ez így azért még nagyon leegyszerűsíti).
Nézzünk is egy példát, adjuk ki a `git status` parancsot.
```
git status
```
Látható, hogy jelenleg a `master` ágon vagyunk. Nézzük meg, milyen branch-ek vannak most a repónkban.
```
git branch
```
Még csak eyg águnk van. Ha kiadjuk a `git branch <új branch neve>` parancsot, akkor készül egy új ág, de arra figyeljünk, ilyenkor még nem megyünk át rá.
Nézzük is meg, hogy tényleg elkészült, a `git branch` paranccsal.
```
git branch atnevezes
git branch
```
Itt a `*` azt jelöli, hogy éppen melyik branch-en vagyunk. Ha kiadnánk a `git status`-t, amit most nem teszünk meg, ne koptassuk el szegényt, ugyanúgy láthatánk, melyik ágon vagyunk.
Menjünk át az új ágra.
```
git checkout atnevezes
```
Itt rögtön látjuk is, a módosításainkkal nem történt semmi. Ha most elmentjük őket, akkor a jelenlegi ágra fogja beilleszteni őket.
```
git add .
git status
git commit -m "Hozzáadtam a txt kiterjesztést a gyümölcskosar fájlhoz"
```
Most ha kiadjuk a `git log --graph --oneline` parancsot, akkor meg is láthatjuk, hogy néz ki a fánk.
### Hogyan épülnek fel?
Ezt nézzétek meg a jegyzetben, röviden annyit, hogy mutatókat, pointereket használ a git, minden mentéspont az előzőre mutat, valamint a megfelelő fájlokra, amiket módosítottunk.
### Ágak közötti mozgás
Mielőtt visszatérnénk a master-re, nézzük meg, milyen fájljaink vannak.
```
ls -la
```
A gyumolcskosar.txt a lényeges.
Térjünk vissza a master-re, és adjuk ki megint az `ls -la`-t.
```
git checkout master
ls -la
```
Látható, hogy visszaléptünk pontosan abba az állapotba, ami volt, mielőtt eljöttünk volna, azaz a gyümölcskosarat nem is változtattuk meg. Ez azért jó, mert két teljesen elkülönülő munkát szét tudunk választani.
Írjuk a gyümölcskosár végére, hogy szőlő és mentsük is el.
```
echo szolo >> gyumolcskosar
git add .
git commit -m "Tettem bele szőlőt is"
```
Most kiadva a `git log --graph --oneline`-t már egy érdekesebb eredményt láthatunk.
Hová tűnt a fájlunk? A git nem fogja alapból jelezni nekünk azt, amit nem lát a jelenlegi mentésből visszamenve.
Ahhoz hogy lássuk a másik ágat is, tegyük hozzá a `--all` kapcsolót.
```
git log --graph --oneline --all
```
Nah, rögtön látjuk a másik ágat is.
Menjünk vissza az átnevezés ágra sé módosítsuk kicsit.
```
git checkout atnevezes
```
Nevezzük át a hordót hordó.txt-re, majd mentsük is el a munánkat.
```
mv hordo hordo.txt
git add .
git commit -m "Adtam kiterjesztést a hordónak is"
```
Egy megismételt `git log`-al láthatjuk is a fánkat.
```
git log --graph --oneline --all
```
### Merge-elés
Az egyik legfontosabb dolog az ágak létrehozása után, hogy azokat be is tudjuk olvasztani valahova. A feladat az lenne, hogy a masterre beillesszük az átnevezés ágon végzett módosításokat.
Ehhez a `git merge <branch neve>` parancsot használhatjuk. Ez a parancs a kiválasztott ágat megpróbálja beolvasztani oda, ahol jeleneleg a `HEAD` mutatónk van.
Menjünk is vissza a masterre. és próbáljuk meg merge-elni az átnevezés ágat.
```
git checkout master
git merge atnevezes
```
Ekkor meg fog nyílni a szövegszerkesztőnk, ugyanis egy
új mentéspontot fogunk készíteni a `master` águnkra.
A feladott merge üzeneten nem kell módosítanunk, teljesen
jó így.
A merge lefut és láthatjuk mi is történt.
Most egy újabb `git log --graph --oneline --all`-al ezt láthatjuk.
Ez a merge commit egyszerre mutat két ágra is.
#### Merge conflict
Mi van akkor, ha ketten egyszerre ugyanazat változtatjuk?
Úgy döntöttünk, Rick barátommal szeretnénk pálinkát főzni, szóval a hordóba teszzük ízlás szerint pár gyümölcsöt.
Menjünk át a saját branch-ünkre.
```
git checkout -b blint
```
A -b kapcsolóval létre tudunk hozni nemlétező branch-et a checkout-nak megadva.
Ha kiadjuk megint a `git branch`-et, láthatjuk, már három ág is van.
Tegyünk bele a hordóba egy nekünk tetsző gyümölcsöt.
```
echo korte >> hordo.txt
```
Mentsül is el. A -a kapcsolóval egy lépést megint meg tudok spórolni.
```
git commit -a -m "Raktam bele körtét"
```
Rick eközben úgy döntött, ugyanebbe a hordóba szilvát szeretne tenni. Menjünk át a master-re és tegyük meg ott.
Tehát:
```
git checkout master
echo szilva >> hordo.txt
git commit -a -m "Raktam bele szilvát"
```
Ha megnézzük megint a gráfunkat, láthatjuk mi a helyzet jelenleg a reponkban.
```
git log --graph --oneline --all
```
Hát most próbáljuk meg merge-lni.
```
git merge blint
```
Oh, no, merge conflict keletkezett.
Nem kell megijedni, nem a világ vége és a git segít ahol tud.
Az a helyzet, hogy egyszerre ugyanazt a sort módosítottuk és a git nem tudta
eldönteni mit tegyen. Megtartsa az egyiket vagy mindkettőt? Mégis mi legyen?
Ezeket a kérdéseket nekünk kell megválaszolnunk.
Először nézzük meg, mi a státusz.
```
git status
```
Ilyenkor a git beírja a fájlba mindkét branch változatát, ezt meg is jelöli nekünk, és tőlünk várja a megoldást.
Nincs mit tenni, mint kitalálni, hogy mi maradjon a fájlban.
Itt láthatjuk nyilakkal a HEAD és a blint branch által eszközölt módosításokat, egyenlőségjellel elválasztva egymástól.
Csináljunk egy vegyes pálinkát, legyen benne mind a kettő.
Ha megnézzük a státuszt, láthatjuk, még mindig ugyanaz a helyzet, mint korábban. Amíg nem mentjük el a módosításunkat, addig ezt fogja kiírni.
```
git commit -a -m "blint branch mergelve és konflikt megoldva"
```
Nézzük meg a gráfot ezután.
```
git --graph --oneline --all
```
Látjuk, a merge commit-unk egyben a konfliktus megoldását is tartalmazza.
Most hogy tudjuk az alapokat, már csak mindezt közösen kell végezzük, online. Erről majd a gyakorlaton lesz szó.
Addig is szép hétvégét, hetet, ki mikor nézi meg kívánok nektek!
