Revision as of 21:59, 18 November 2019

Fájl kezelés

Munkaterület kezelése

Ha van lokális módosítás a working copy-ban, akkor a commit tree legtetején megjelenik a //WIP (Work In Progress) sor üres körrel, ami annak a branch-nek az utolsó commit-jából származik, ami éppen a working területre be van töltve.

A //WIP mellett található a módosított, új és törölt fájlok listája, amit az utolsó commit-hoz képest kell érteni. Értelem szerűen a ceruza mögötti szám a módosított fájlok száma, a + mögött a hozzáadott és a - mögötti a törölt fájlok darabszáma. A //WIP részbe beírhatjuk kapásból a leendő commit summary részét. Nyugodtan nyomjunk enter-t, ez még nem commit-ál semmit csak a fában fog már elve a leendő commit nevével szerepelni. A fenti képen a //WIP sor a branch1 lokális branch-ből származik, ami a jelenlegi check-out-olt branch, mivel a branch1 neve mellett van a kis zöld pipa.

Ha van módosított fájl, és nem a //WIP soron állunk akkor bal felül megjelenik egy figyelmeztetés egy gombbal, hogy módosított fájl a munkaterületen. A gombbal kapásból a //WIP-re ugorhatunk, ahol megjelennek a módosított fájlok a baloldalon:

Ha a fájl neve fölé visszük az egeret, akkor megjelenik a 'Stage file' gomb, amivel csak ezt a fájlt adhatjuk a stage-hez. Az 'Unstaged files' szekció fölötti gombbal az összes még nem stage-elt fájlt hozzáadhatjuk a stage-hez:

Commit részletek

Fájlok listázása

Ha a commit fában egy commit-ra kattintunk, akkor megjelenik a baloldalon a commit részletek. Tartalmazza commit címét, a commit user-t, valamit a commit-ban szereplő fájlok listáját.

• Commit id: A commit száma az ablak legtetején van. A példában: 0d9ab088667b93aa99336bd966afcbf1a5823ce2, aminek az első 6 karaktere van megjelenítve.
• Parent: A commit szülője a commit fában a commit címe alatt található, ez a példában: 409039643a6d770f73b5f4327fdc25510ba73162.

A ceruza jelenti a módosított fájlt, a zöld+ a hozzáadott fájlt, míg a piros'-' az adott commit-ban törölt fájlt.

Ha egy olyan commit-t nézünk, ami merge-ből keletkezett, akkor két parent ID lesz a commit részletekben:

A képen kiválasztott commit egy merge commit. A jobb oldalon, a commit részletekben láthatjuk hogy két szülője van:

• 343831030f0d41d579270f95d9458cd845b6adaa
• f3ee62d54a8eed112530b28a1880b68575d7355b

File history

A commit részletekben kattintsunk jobb clikkel a fájl nevére, majd válasszuk a 'File History'-t.

A file history-ban baloldalon láthatjuk a fájlt befolyásoló commit-okat. A legelső commit van legalul.

• Ha egy adott commit-ra kattintunk, akkor megjelenik a baloldalon a diff ablak, ahol az előző commit-hoz képest láthatjuk a diff-et.
• Ha a commit listában a commit id-ra kattintunk, akkor a commit fában az adott commit-ra ugrik

Blame

A blame funkcióval azt nézhetjük meg, hogy egy adott fájlban melyik sort ki hozta létre. Ez megfelel az SVN-ben az annotate-el. A 'Blame' több helyről is elérhető. Egyrészt a fájl commit history-ában, ha a diff ablak feletti választóban a 'File view'-t választjuk: A Blame-et a File view-ban külön be kell kapcsolni a jobb oldalon lévő 'Blame' gombbal.

Miden egyes sor mellé balra oda van írva hogy melyik commit-ban keletkezett és a commit előtt látható a user avatárja. Ha felé visszük az egeret, akkor láthatjuk, hogy ki hozta létre a commit-et:

A Blame és a File commit history is elérhető minden fájl diff ablakának fejlécéből a 'Blame' ill 'History' gombokkal:

Diff

A diff ablakot mindig a jobb oldali fájl lista ablakból nyithatjuj meg A GitKraken-ben a diff ablakban nagyon sok nézet elérhető. Alapértelmezetten a szabványos diff jelölést használja, és a változtatásokat alapértelmezetten úgynevezett hunk-okba (nagy egység) csoportosítva mutatja. Minden egyes hunk csak a módosított rész pár soros környezetét tartalmazza.

A diff nézetben a két fájl tartalmát egybe írva láthatjuk minden egyes hunk-ban, nem egymás mellett minta meld-ben. Minden hunk-nak van egy @@ -al kezdődő fejléce. A fejléc szintaktikája az alábbi:

@@ -[<régi fájlban a hunk kezdete>, <hossza>] +[<új fájlban a hunk kezdete>, <hossza>] @@

• A @@ utáni részben a '-' jelöli a régi fájlt és a '+' az új fájlt. A régi és fájl jelentése attól függ hogy mit diff-elünk mivel. Ha egy commit-ban szereplő fájlban nézzük a diff-et, akkor a '-' jelöli az új commit előtti állapotot és a '+' az új commit-ban lévő állapotot. A diff-ben nem az egész fájl tartalmát fogjuk látni, csak azt ami változott a régihez képest.
• A - és a + után is két-két számot láthatunk. Az első azt mondja meg, hogy az adott hunk (fájl részlet) hányadik sorban kezdődik, míg a másik azt mondja meg hogy az adott hunk hát sort tartalmaz az első ill. a második fájlból.

A fenti példában két hunk-ot látunk. A másodikban a fejléc az alábbi:

@@ -7,3 +9,5 @@

Ez azt jelenti, hogy a réig fájlban (-) a megjelenített sorok a 7. sorban kezdődnek, és 3 sort tartalmaz a hunk. Az új verzióban (+) a megjelenített sorok már a 9. sorba kerültek, és 5 sort tartalmaz már az új verzió:

Minden 'hunk' ban a +zöld sorok jelölik az új részt (ami a régiben verzióban nem volt benne) és a -piros kezdetűek a hiányzó részt, ami az új verzióban már nincs benne.
A diff nézetet a jobb felső sarokban lévő gombokkal vezérelhetjük:

• 'Hunk view': baloldali gomb, ez az alapértelmezett, diff szabványú megjelenítés, csak a módosult szekciókat mutatja, ezt láthatjuk a fenti példában.
• 'Inline view': második gomb, itt is diff szabványban láthatjuk a különbségeket, de nem hunk-ban, az egész fájlt egyben látjuk.
• 'Split view': jobboldali gomb, hagyományos osztott képernyős nézet, mint a meld-ben.

Ha 'Hunk view'-ban vagyunk, akkor az egyes hunk-okban lévő módosításokat elvethetjük a Hunk jobb felső sarkában lévő 'Discard hunk' gombbal:

Stage

Stage alapok

A stage a commit-ra szánt fájlok gyűjtőhelye, egy átmeneti lépés a munkaterület és a repository között. A munkaterületen és a stage-en lévő fájlokat a jobb oldali mezőben láthatjuk:

A stage-be be és ki lehet rakni a fájlokat egészen a commit-ig. Csak az lesz commit-álva ami a stagen van.

Hunk stage-be rakása

Nem csak egész fájlokat lehet a stage-hez adni, lehet csak egy fájl módosításainak részleteit is. Nyissuk meg az 'Unstaged files' szekcióban lévő fájlt a diff-ablakban:

A diff ablakban a stag-hez lehet adni egyesével a hunk-okat vagy a hunk-on belül akár egyetlen egy módosított sort is. Egy módosított fájlból egy hunk-ot a hunk jobb felső sarkában lévő 'Stage hunk' gombbal tehetjük meg:

Tegyük fel, hogy a file1.txt -ben két hunk található, a diff ablak az alábbi:

Ha itt az első hunk-ot hozzáadjuk a stage-hez a 'Stage hunk' gomb megnyomásával, akkor a stage-be bekerül a file1.txt-nek egy olyan változata, amiben csak az első hunk-ban szereplő változtatás, vagyis a 'hozzáírok az elejéhez' változtatás szerepelni fog, de a 'hozzáírok a végéhez' változtatás már nem fog szerepelni. Kattintsunk a file1.txt-re a jobb oldali 'Staged files' szekcióban, hogy megnyissuk a stage-ben lévő file1.txt diff ablakát:

Láthatjuk, hogy csak a 'hozzáírok az elejéhez' szerepel benne. A stage-be rakott hunk-ot az 'Unstage hunk' a-l lehet visszavonni. Ha nem marad egy fájlnak olyan változtatása, ami a stage-ben van, csak akkor tűnik el a 'Staged files' szekcióból.
A file1.txt továbbra is látszik az 'Unstaged files' szekcióban, mivel van még olyan része a fájlnak, ami nem lett a stag-be rakva. Ha megnézzük a diff ablakban az Unstaged file1t.txt-t láthatjuk, hogy most már csak a 'hozzáírok a végéhez' módosítást tartalmazó hunk látszik:

Egy sor stage-be rakása

Lehet sorokat egyesével is a stage-be rakni. Ehhez az 'Unstaged files' szekcióból nyissuk meg diff módban a fájlt. Majd vigyük az egeret a stage-be rakni kívánt sor elé. Ekkor megjelenik egy zöld+ a sor előtt.

A sor elé kattintva a stage-be kerül a fájlnak egy olyan változata, amiben csak ez a módosítás szerepel csak a lokális repoban lévő legfrissebb verzióhoz képest.

A fenit példában rákattintottam a 'hozzáírok az elejéhez2' sorra, így az már nincs kijelölve az 'Unstaged files' nézetben megnyitott fájlban.
Ha most megnyitom a stage-ben lévő file1.txt-t a diff ablakban, akkor a stage -be került sor zöld-el szerepel. Ha elé visszük az egeret, akkor egy piros '-' jelenik meg, ezzel tudjuk kivenni a stage-ből a sort:

Branch

Pull és Push működése

https://support.gitkraken.com/working-with-repositories/pushing-and-pulling/
A merge és rebase stratégiák nem csak két branch egyesítése közben értelmezett, akkor is mikor egy meglévő branch-en kiadjuk a pull ill. a push parancsot. Ne feledjük el, hogy a git lokálisan is fenntart egy repository-t, amibe commit-al tudunk változásokat bejuttatni. Tehát az SVN-el ellentétben a változásokat a lokális repository-ba kell beadni, majd a PUSH-al ill PULL-al szinkronizáljuk a lokális és távoli repo-t.
A lokális repo-nk egy másolata a távoli repo-nak, minden branch-re azt az utolsó commit-ot tartalmazza, ami a PULL pillanatában a legújabb volt. Aztán ahogy telik az idő, mind a távoli, mind a lokális repositor-nkba ugyan azon a branch-en keletkezhetnek új commit-ok ezért tekinthetjük úgy hogy hogy a push és a pull is két branch-et egyesít, a pull a távoli branch-et mergeli a lokális repo-ra míg a push a lokálisat mergel-i a távolira.

Note
Fontos azt is érteni, hogy a Push és Pull a lokális és távoli commit-okat szinkronizálja, a stage-ben lévő fájlokhoz és a lokálisan módosított még stage-be sem került fájlokhoz semmi köze. Szigorúan véve a pull futtatásához nem volna szabad hogy stage-elt vagy lokálisan módosított fájlok legyenek nálunk, mert a merge után fejbe fogja vágni a working tree-t is. Itt jön a képbe a stach, lásd itt Stash

A fenti példában a távoli repo-ban lévő master -en van egy olyan commit (C2`) ami az utolsó pull után keletkezett, így a lokális repo-ban nincs meg. A lokális repo-ban is van két új commit a master-hez képest.

GitKraken-ben ez a következő képen nézne ki:

A lentebbi kék doboz az origin (original repository, vagyis ahonnan a lokálisat klónoztuk) a fentebbi zöld doboz pedig a lokális mutatónk. Láthatjuk, hogy a távoli repo-ban a master branch-en vagy a 'second-commit' ami lokálisan hiányzik, viszont lokálisan van 2 új commit, ami a távolin nincs meg.

Push

Push alapok

Note
A push csak akkor tud lefutni, ha a csak lokálisan létező commit-okat fast-forward merge-el egyesíteni lehet a távoli repo-val

A távoli repo-ban akkor tudunk egyszerűen push-olni, ha ott nincs olyan commit ami a lokálisan nincs meg. Nézzük az alábbi példát:

A fenti példában az origin-on (remote) lévő utolsó commit lokálisan is megtalálható. Ezért a push minden további nélkül lehetséges. Ebben az esetben a git egy fast-forward merge-t fog végrehajtani, vagyis fogja a lokális új commit-okat, majd ráfűzi a remote branch végére, végül átállítja a master mutatót:

Force push

A gond csak akkor van, ha a remote-on (origin) már van új commit. Ebben az esetben a fast-forward merge nem lehetséges, akár csak a lenti példában:

Ebben az esetben GitKraken az alábbi figyelmeztetést fogja adni:

Egyrészt felajánlja hogy elsőként futtassunk egy PULL-t (amiből jelen esetben 3-way merge lenne, lásd a Pull fejezetben), vagy a drasztikus Force push-t. A Force-push a teljes távoli repository commit history-t felülírja a lokális commit history-val, úgy hogy minden olyan commit el fog veszni, ami lokálisan nem volt meg. Ez egy visszavonhatatlan lépés. A GitKraken figyelmeztet is rá:

Induljunk ki az alábbi állapotból:

Ha tényleg a Force push-t választjuk, akkor a fenti példában a 'Second commit' (ami nem volt meg lokálisan, csak a távoli branch-en létezett) eltűnik, és az új log fa így néz ki:

Ez a sematikus ábra szintjén a következőt fogja jelenteni:

A távoli branch-ből eltűnt a C2' commit.

Konfliktus push esetén

..TODO

Pull

Pull alapok

Pull esetében 4 lehetőségünk van. Ebből 3 valóban merge-li is a táli repo-t a lokális repora. Bármelyiket is választjuk ebből a 3 lehetőségből, ha konfliktus mentesen lefut a Pull, akkor a lokális repository-nk biztosan olyan állapotba kerül, hogy Push-olni lehet a remote repo-ba, mivel ott biztosan elég lesz a fast-forward merge. (Részletek lentebb)

GitKraken-n a négy opció az alábbi módon van felkínálva:

A kiválasztott opció lesz a default működlés ha rányomunk választás nélkül a Pull-ra.

Fetch

Nem frissíti a lokális repot, csak letölti a commit "meta" adatokat a táli repo-bol, hogy ki tudja rajzolni a commit tree-t.

Fast-forward only

Ez megfelel a fast-forward Push működésnek, csak fordítva. Vagyis a távoli branch-ben vannak új commit-ok a lokálishoz képest, de lokálisan nincs olyan commit, ami a remote-ban ne szerepelne, sőt lokálisan semmilyen még nem commitált módosítás sem létezhet. Fast-forward merge esetében a lokálisan hiányzó commit-okat a git hozzá fogja biggyeszteni a lokális branch végéhez, majd a lokális branch mutatót át fogja állatni. (lokális fast-forward). Mikor majd Push-olni akarjuk a csak lokálisan létező commit-okat, a git-nek nem lesz más dolga, mint hogy ezeket ráfűzze a távoli repoban a branch végére. A 'Fast-forward only' pull nem fog sikerülni ha nem lehet simán előre mozgatni a mutatót, vagyis egy merge commit-ra lenne szükség mert lokálisan is történt módosítás.

Tegyük fel, hogy a távoli repoban lévő branch-en létrejött az A1 és A2 commit, amik nincsenek meg még a local repo-ban.

Ekkor ha végrehajtjuk a 'fast-forward' pull-t, akkor a git a lokális C1-re rá fogja fűzni az A1 és A2-t, majd a head mutatót az A2-re fogja előre mozgatni (forward).

Fast-forward if possible

Ebben az esetben meg fogja próbálni a fast-forward-ot, de ha nem lehetséges, akkor a 3 utas merge-t fogja alkalmazni, és létre fog hozni egy merge commit-ot, aminek a nevében is benne lesz, hogy ez miért keletkezett:
Fontos, hogy a merge commit csak lokálisan fog létezni addig amíg nem nyomunk egy push-t is rá.

Rebase

Ennek csak akkor van értelme, ha a távoli repo-ban és az újban is vannak új commit-ok, ezért nem lehet fast-forward merge-t alkalmazni. Lokálisan, a távoli utolsó commit-ra rá fogja fűzni a lokális új commit-okat, így nem lesz plusz leágazás a commit-logban, az egész egy folytonos vonal esz, viszont elveszik az az információ, hogy a remote és a local elmászott egymástól (ami egyáltalán nem baj, tisztán tartja a commit history-t). Tegyük fel hogy mind lokálisan mind a távoli repoban 2-2 commit történt. GitKraken-ben így néz ki a commit fa:

A távoli repo-ban a 'branch1'-en a 'remote comm r3' és r4. Ezt jelöli a felső zöld 'branch1' téglalap: Lokálisan 'local comm r1' és r2 commit-ok voltak. Jelenleg a lokális repó a 'local comm r2'-re mutat, mivel mellette van a pipa és a kis monitor szimbólum: . A közös ős a 'local comm 5'.
Ha most 'Pull (rebase)'-t választjuk, akkor a távoli repo 'remote comm r4'-re rá fogja ültetni a 'local comm r1'-et.

A rebase után nem fog többet látszani, hogy a 'local comm r1'-nek valójában a 'local comm 5' volt az őse.
Ha Push-t is nyomunk, akkor a változások már egy egyszerű 'Fast forward' merge-el el lehet végezni, hiszen nincs más dolga a git-nek, mint előre mozgassa a mutatót:

A 'Force push'-al ellentétben itt nem veszett el a távoli 'remote comm r3' és r4.

Auto stash

... TODO ...

Konfliktus PULL-esetén

...

A fenti képen conflit volt a pull-ban. Amit feloldottam. Most látható, hogy három águnk van. Lilával láthatjuk a remote branch-et. Zölddel láthatjuk a lokális két commit-unkat, amit még nem push-oltunk. A local-commit 2-ből két felé ágazik a gráf. A sötétkék négyzet alakú ág az automatikusan mentett stash, amiben a pull-merge előtti állapota található a még nem commit-ált fájloknak. Jelen esetben ebben most csak a file1.txt-ban. Ha megnézzük a tartalmát, akkor láthatjuk, hogy ebben csak a lokális módosítás van benne. A gráf legtetején zöld szaggatott körrel található a merge eredménye, ami most csak a file1.txt feloldott konfliktusát tartalmazza úgy ahogy megjelöltük a diff során. Az auto-stage-be rakott eredeti fájlon három műveletet hajthatunk végre:

• Apply stage
• Pop stage
• Delete stage

Stach

Tag

Pull request

A 'Pull request'-el kérhetjük meg a távoli repository tulajdonosát, hogy nézze át az általunk készített módosítást (review), és ha megfelelőnek találja, akkor merge-ölje be a változtatásokat a saját branch-ébe. Ugyan a 'Pull request' nem része a core git szabványnak, megtalálható mind a négy nagy git szolgáltatónál (GitHub, GitLab, Butbucket és AzureDevOps). Ha a master branchen (vagy bármilyen kiemelt, központi branchen) ha be van kapcsolva a 'pull request' funkció, akkor a lokális branch-böl nem lehet közvetlen Push-al feljuttatni a változtatásokat: