7,540
edits
Changes
→Stage
<br>
===Stage===
==Pull és Push működése==
https://support.gitkraken.com/working-with-repositories/pushing-and-pulling/<br>
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. <br>
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|Stash]]}}
:[[File:ClipCapIt-191112-233259.PNG|400px]]
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 van is van két új commit a master-hez képest.
<br>
GitKraken-ben ez a következő képen nézne ki:
:[[File:ClipCapIt-191112-231640.PNG]]
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.
<br>
<br>
==Push==
===Push alapok===
Ha 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:
:[[File:ClipCapIt-191112-233007.PNG|400px]]
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 csinálni, vagyis fogja a lokális új commit-okat, ráfűzi a remote branch végére, majd átállítja a master mutatót:
:[[File:ClipCapIt-191112-233236.PNG|400px]]
<br>
<br>
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, a GitKraken pl az alábbi figyelmeztetést fogja adni:
:[[File:ClipCapIt-191112-232402.PNG]]
Egyrészt felajánlja hogy elsőként futtassunk egy PULL-t (amiből jelen esetben 3-way merge lenne, lásd a [[#Pull|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á:
:[[File:ClipCapIt-191112-234022.PNG]]
Ha tényleg a Force push-t választjuk, akkor a fenti példában a 2. commit (ami nem volt meg lokálisan) eltűnik, és az új log fa így néz ki:
:[[File:ClipCapIt-191112-234123.PNG]]
<br>
<br>
===Konfliktus push esetén===
..TODO
<br>
<br>
==Pull==
===Pull alapok===
Pull esetében 4 lehetőségünk van. Ebből 3 valóban merge-i is a vá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:
:[[File:ClipCapIt-191112-234514.PNG]]
A kiválasztott opció lesz a default működlés ha rányomunk választás nélkül a Pull-ra.
<br><br>
* '''Fetch''': nem frissíti a lokális repot, csak letölti a commit "meta" adatokat a váli repo-bol, hogy ki tudja rajzolni a gráfot.
* '''Fast-forward only''': Ez megfelel a fenti leírt 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 esetében a lokálisan hiányzó commit-okat a git a 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.
* '''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:
[[File:ClipCapIt-191112-235732.PNG]]<br>
Fontos, hogy a merge commit csak lokálisan fog létezni addig amíg nem nyomunk egy push-t is rá. Ha Push-t nyomunk ... TODO ...
* '''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). GitKráken-ben így néz ki egy Rebase-elt Pull:
:[[File:ClipCapIt-191113-000524.PNG]] <br> .... TODO ... Mi volt a kiindulási gráf .... mit hova mozgat ...
Természetesen nem veszett el (nem úgy mint a Force Puhs-nál), a távoli 'remote commit2' -re ráfűzte a 'local commit' és 'local-commit2' változtatásokat, így már tudnánk push-olni.
<br>
===Auto stash===
... TODO ...
<br>
===Konfliktus PULL-esetén===
...
:[[File:ClipCapIt-191113-003023.PNG]]
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
<br>
<br>
