7,540
edits
Changes
→Rebase két külön branch-en
=Fájl kezelésalapok=
==Munkaterület kezelése==
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:
:[[File:ClipCapIt-191117-144240.PNG]]
<br><br>
==Diff==
:[[File:ClipCapIt-191116-193013.PNG]]
<br>
<br>
= Commit ügyek =
=== Commit-ok keresése ===
GitKraken-ben a jobb felső sarokban lévő nagyítóra kattintva kereshetünk a commit-ok nevében.
:[[File:ClipCapIt-191126-002923.PNG]]
A keresett név beírása közben csak azokat a commit-okat emeli ki a fában, amire illeszkedik a név. A kereső input melletti le-fel nyíllal ugrálhatunk a találatokon. Alapból az utolsó 2000 commit-ot mutatja a fa.
<br>
<br>
===Checkout commit ===
Tetszőleges commit-ra rá lehet állítani a lokális head mutatót, nem kell hogy egy branch legutolsó commit-ja legyen. Ehhez a commit fában jobb click-menüben válasszuk a 'Check out this commit' lehetőséget. Ekkor láthatjuk, hogy a pipa mellett nem a branch neve lesz, hanem csak annyi hogy 'Head', ami külön branch-ként nem jelenik meg a bal oldali local-branch listában:
:[[File:ClipCapIt-191125-183916.PNG|700px]]
<br>
<br>
===Revert commit ===
...TODO...
<br>
<br>
===Reset head to commit ===
...TODO...
* Soft:
* Mixed:
* Hard:
<br>
<br>
===Drop commit ===
...TODO...
<br>
<br>
===Move commit ===
...TODO...
<br>
<br>
=Branch=
...
<br>
<br>
==Új branch létrehozása==
=== branch létrehozása az aktuális head-ről ===
Amikor megnyomjuk a felső menüsorban a 'branch' gombot [[File:ClipCapIt-191125-182138.PNG]], akkor attól függetlenül, hogy mit nézegetünk éppen a commit fában, mindig a lokális repon-k aktuális branch-ének (checked out) az aktuális head mutatójánál fogja létrehozni az új branch-et, vagyis ráállít még egy head mutatót az új branch nevével. Tehát a lényeg, hogy a bal oldali branch listában és a a commit tree-ben hol van a pipa: <br>
:[[File:ClipCapIt-191125-182559.PNG]]
Ha a head mutatót elmozgattuk egy régebbi commit-ra, akkor oda fogja létrehozni a branch-et ahova a head mutat.
<br>
<br>
=== branch létrehozása tetszőleges commit-ról ===
Tetszőleges commit-ról lehet branch-et készíteni a commit fában. Ehhez az adott commit jobb-click menüjében válasszuk a 'Create branch here' lehetőséget:
:[[File:ClipCapIt-191125-215231.PNG|300px]]<br>
Majd írjuk be az új branch nevét. Ekkor a head az új branch-re fog ugrani, vagyis ez a branch lesz a checked out branch. Ez természetesen csak a lokális repoban fog létezni, ahhoz hogy a távoliba is bekerüljünk PUSH-olni kell.
:[[File:ClipCapIt-191125-215620.PNG]]
Láthatjuk, hogy a zöld pipa rákerült az újonnan létrehozott 'branch2'-re, ami csak a lokális branch listában szerepel, a remote-ban nem.
<br>
<br>
== Merge ==
<br>
<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]]}}
<br>
A GitKraken-ben ez a következő képen nézne kimutatja a lokális és távoli repo-k eltérését:
:[[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>
==Push==
===Push alapokFast-forward push===Ha {{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 a következő példát. Láthatjuk, hogy a távoli repo-ban nincs újabb commit a branch-en mint a lokálisban, viszont a lokálisban született két új commit, az alábbi példát: A1 és A2. :[[File:ClipCapIt-191117191119-181427000023.PNG|400px500px]]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 push elvégezhető 'fast-forward ' merge-t fog végrehajtani, vagyis fogja a lokális új el. A git az A1 és A2 commit-okata távoli C1 után fogja másolni, majd ráfűzi a remote branch végére, végül átállítja a -master head mutatót: a távoli A2-re fogja állítani. :[[File:ClipCapIt-191117191119-181435000225.PNG|400px500px]]<br><br>
===Force push===
Ha a távoli és lokális branch-en is történt módosítás, akkor a push nem lehetséges, mert egy 'fast-forward' merge-el nem tudja a git egyszerűen felmásolni a lokális módosításokat. Ebben az esetben az egyik lehetőségünk a 'Force push', ami hatására a teljes távoli branch-et és commit histor-yt helyettesíteni fogja a git a lokális branch-l és lokális commit history-val, így minden távoli olyan változtatás ami lokálisan nem volt meg el fog veszni.
Tegyük fel, hogy a távoli branch-en létrejött az A1 commit, ami már lokálisan nem létezik, és lokálisan létrejött a B1 és B2 commit, ami a távoli branch-en hiányzik. Mivel mind lokálisan mind távol is vannak új commit-ok, a 'Fast-forward' push nem lehetséges.
:[[File:ClipCapIt-191118-230025.PNG|500px]]
Ha a 'Force push' lehetőséget választjuk, akkor a távoli A1 commit el fog veszni, mivel az nem volt meg lokálisan.
:[[File:ClipCapIt-191118-234932.PNG|500px]]
<br>
<br>
:[[File:ClipCapIt-191112-232402.PNG]]
Egyrészt a GitKraken 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 futtathatjuk 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. '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:
:[[File:ClipCapIt-191112-234123.PNG]]
<br>
<br>
<br>
<br>
==Pull==
===Pull alapok===
Pull esetében 4 lehetőségünk van. Ebből 3 valóban merge-i li is a váli 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.
<br><br>
[[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<br>A merge-t nyomunk ... TODO .öt a két ág találkozásánál csak egy pötty-el jelöli a GitKraken ellentéten a normál commit-al, amit egy nagyobb kör jelöl benne a commit-ot létrehozó avatárjával.Tehát a merge commit-ot nem látszik hogy ki hozta létre: <br>[[File:ClipCapIt-191126-002326.PNG|250px]]
<br>
===Rebase azonos branch-en===
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 a távoli branch-en létrejött az A1 commit, ami már lokálisan nem létezik, és lokálisan létrejött a B1 és B2 commit, ami a távoli branch-en hiányzik. Mivel mind lokálisan mind távol is vannak új commit-ok, a 'Fast-forward' pull nem lehetséges.
:[[File:ClipCapIt-191118-230025.PNG|500px]]
Ekkor ha a 'Pull (rebase)' lehetőséget választjuk, akkor a git le fogja tölteni a távoli új commit-okat, és ezt be fogja ékelni a lokális régi és új commit-ok közé, vagyis az A1-et beékeli a C1 és B1 közé. Úgy is mondhatjuk, hogy az új commit-okat ráfűzi a távoli módosításokra (amíg nem nyomunk push-t is, addig csak lokálisan)
:[[File:ClipCapIt-191118-231423.PNG|500px]]
<br>
<br>
GitKraken-ben ez a következő képen néz ki. Tegyük fel hogy mind lokálisan mind a távoli repoban 2-2 commit történt:<br>
:[[File:ClipCapIt-191117-223115.PNG]]<br>
A távoli repo-ban a 'branch1'-en a 'remote comm r3' és r4. Ezt jelöli a felső zöld 'branch1' téglalap: [[File:ClipCapIt-191117-224443.PNG]]
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: [[File:ClipCapIt-191117-224417.PNG]]. A közös ős a 'local comm 5'. <br>
Ha most 'Pull (rebase)'-t választjuk, akkor a távoli repo 'remote comm r4'-re rá fogja ültetni a 'local comm r1'-et. (lokálisan) <br>
:[[File:ClipCapIt-191117-223204.PNG]]<br>
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. <br>
Ha Push-t is nyomunk, akkor a változásokat már egy egyszerű 'Fast forward' merge-el el is fel lehet juttatni, hiszen nincs más dolga a git-nek, mint előre mozgassa a mutatót:
:[[File:ClipCapIt-191117-223325.PNG]]
A 'Force push'-al ellentétben itt nem veszett el a távoli 'remote comm r3' és r4.
<br>
<br>
===Rebase két külön branch-en===
Ha van egy master branch, ahova mindent visszavezetünk, és van egy külön munka branch-ünk, amin dolgozunk, akkor gyakori esemény, hogy a master branch-en annyira előre haladtak a dolgok, hogy a munka branch-et már nem lehetne mergelni a masterre. Ebben az esetben a munka branhc-et rebase-leni kell a master-re, vagyis rá kell rakni a tetejére.
Alább látható, hogy a master-re rákerültek újabb comit-ok a munka branchhez képest.
:[[File:ClipCapIt-220804-121740.PNG]]
<br>
Azt szeretnénk, hogy a munka branch-et rebase-eljük a master tetejére, tehát: rebase: munka -> master<br>
A végeredmény így fog kinézni.
:[[File:ClipCapIt-220804-121758.PNG]]
<br>
<br>
Egy élő példa: <br>
* master: Van egy master branch-ünk: PP-21414. (a lokális mutató egyel hátrébb van mint a remote, a remote a lényeg).
* munka: És van egy munka branch-ünk: redis-webGUI
A leágazás óta 4 commit van a master-en a munka branch-hez képest. De van egy kis trükk. A master-en a 3. commit (ahol a lokális mutató épp áll) az megegyezik a munka branch 2. commit-jával 'mysql db +..'.<br>
Ez azért van, mert a 'redis-webGUI' branch egy másik munka branch-ből származik. Ennek a másik munka branch-nek az utolsó commit-ja a 'create separate mysql db..' volt.
# Ki lett húzva egy munka branch a masteről az 'Install Basic' commit után. Ennek a neve az volt hogy 'munka-branch1'. Ez már nem látszik a fában, mert már törölve lett: long/PP-21.. -> 'munka-branch1'
# A 'munka-branch1'-en született egy commit: 'create separate mysql db'.
# Ki lett húzva egy új branch (redis-webGUI) a 'munka-branch1' branch-ből: 'munka-branch1' -> 'redis-webGUI'
# Az új branch-en (redis-webGUI) született egy darab commit 'Redsi web GUI' címmel.
# A 'munka-branch1' branch mergelve lett (pull request-el) a master-re (long/PP-21..), majd törölve lett. merge 'munka-branch1' -> 'long/PP-21..'
# A törölt 'munka-branch1' branch egyetlen commit-ja (create separate mysql db) megjelent a master tetején.
# A master-en született egy új commit: 'User profile mock..'.
# Elhatároztuk, hogy a 'redis-webGUI' munka branch-et rebase-eljük a master tetejére.
:[[File:ClipCapIt-220804-120859.PNG]]
<br>
<br>
És mi a végeredmény:
# A 'redis-webGUI' branch most már a master-ből nő ki. Mivel a 'redis-webGUI' első commit-ja már rajta volt a masteren korábban, ezért az a commit nem került ráfűzésre a master-re, csak a 'Redis web gui' commit lett ráfűzve. Most már a 'redis-webGUI' branch tartalmazza az összes változtatást ami idő közben a master-en történt (három ilyen commit van).
:[[File:ClipCapIt-220804-122950.PNG]]
===Auto stash===
<br>
=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) 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 a távoli repoba.
# Létre kell hozzunk egy új fork-ot a távoli master branch-böl
# Clone-ozni kell az új fork branch-et, hogy lokálisan is meglegyen.
# El kell végezni lokálisan a módosításokat, majd lokálisan commit-lni.
# Push-olni kell a lokális fork branch-en a commit-okat a távoli fork branch-re.
# Fel kell adni egy pull request-et a távoli fork branch-ről a távoli master branch-re.
Ha a review-el jóváhagyja a változtatásainkat, akkor merge-ölni tudja azokat a távoli master branch-be. A review és merge felületet már mindig a git szolgáltatók adják, ez már nem része a GitKraken-nek.
<br>
<br>
=Troubelshooting=
==File watcher failed to start for this repository==
https://techsparx.com/blog/2018/02/gitkraken-inotify.html<brr>
Type this command:
$ cat /proc/sys/fs/inotify/max_user_watches
8192
This is the limit on your computer.
Each inotify watch consumes a modest amount of memory. On a 64-bit computer like this one, each consumes 1 KB, so 8,192 watches consumes about 8 MB of memory. On a 16GB main memory computer that's a drop in the bucket.
Temporarily increasing the limit is this simple:
# echo 99999 > /proc/sys/fs/inotify/max_user_watches
After which you'll get this:
$ cat /proc/sys/fs/inotify/max_user_watches
99999
To make a permanent change, set fs.inotify.max_user_watches= in sysctl settings. On some systems (Debian/Ubuntu/etc) those settings are in /etc/sysctl.conf and on some others there will be a file in /etc/sysctl.d.
After editing the sysctl settings, run this:
# sysctl -p
fs.inotify.max_user_watches = 99999
Putting it on one line:
# echo fs.inotify.max_user_watches=99999 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Or on certain other systems:
# echo fs.inotify.max_user_watches=99999 | sudo tee /etc/sysctl.d/40-max-user-watches.conf && sudo sysctl --system
<br>
==Pre-receive hook declined==
A pre-receive hook-ok két helyen lehetnek beállítva.
1. Lokálisan, az adott repository .git/hooks mappában. Itt olyan sh script-eket kell berakni, amik ellenőrzik a commit-ot. A GitKraken-ben itt van:
:[[File:ClipCapIt-211026-151345.PNG]]
<br>
<br>
2. A távoli repoóba, ahova push-olni akarunk.
<br>
<br>
Ha ezek közül egyiket sem szegjük meg, akkor az lehet a baj, hogy a commit-ban lévő username/email nem ugyan az mint a távoli repóban, pl BitBucket-ben.
:[[File:ClipCapIt-211026-151626.PNG]]
A profil-t a jobb felső sarokban választhatjuk ki. Minden profil tartalmaz egy nevet és egy email címet. A profilokat a preferences/profiles-ban állíthatjuk be:
:[[File:ClipCapIt-211026-151753.PNG]]
Bitbucket szerver esetén itt az az email cím kell és név, ami a Bitbucket profilban meg van adva.
{{warning|A commit készítésekor kiválasztott profil számít, nem a push-kor kiválasztott profil. Ha a commit-ot rossz profillal csináltuk, akkor nem számít hogy a push alatt mi van kiválasztva}}
A rossz profillal készített commit-ot úgy vonhatjuk vissza, hogy az előző commit-ra jobb klikk, majd:
:[[File:ClipCapIt-211026-152244.PNG]]