Changes

Jump to: navigation, search

Git basics

16,337 bytes removed, 16:45, 16 November 2019
GitKraken alapok
* -d: mappa szinten hasonlítson össze. Enélkül egyenként feldobálja az összes fájlt külön meld ablakban.
:[[File:ClipCapIt-160930-133557.PNG|1100px]]
===REMOVE===
Git-ben minden egyes commit egy pillanat felvétele a világnak. Ezen pillanat felvételek egymásra mutatnak. (Baloldalon van a legrégebbi, és ahogy haladunk előre az időben mindig egy újabb commit lesz leglelől, ami rá fog mutatni az előzőre. Egy branch nem más mint egy kitüntetett mutató egy adott pillanat felvételre (narancssáraga). Ha egy branch-be kommitálunk, akkor egy saját commit láncot indítunk el arról pontról. A git úgy tartja nyilván az aktuálisan kiválasztott branch-et (ami be vat töltve a munkaterületre) hogy ráállítja a speciális HEAD mutatót. Igazából branch váltás közben nem csinál mást, mint hogy a HEAD mutatót átállítja egy másik branch-re, és az abban a snapshot-ban lévő fájlokat tölti be a munkaterületre.
:[[File:ClipCapIt-160930-144445.PNG|500px]]
A fenti képen az látható, hogy két branch-ünk van. A '''master''' branch (amit a git init magától létrehoz, hogy legalább egy branch legyen a repóban) és a '''test''' nevű branch. Jelenleg a munkaterületünkre a '''master''' van betöltve, mivel arra mutat a '''HEAD''' mutató. A test branch-be már volt egy commit a master hez képest.
$ git branch adam3
</pre>
<br>
<br>
GitKraken-ben kétféle képen hozhatunk létre branch-et. A legegyszerűbb ha megnyomjuk a Branch gombot a felső sávban:
:[[File:ClipCapIt-191114-210055.PNG]]
Ennek a hatására létre fog hozni egy lokális branch-et azon a ponton, ahova a lokális head mutat, vagyis az aktuális lokális branch-en az utolsó commit-ra. A gomb megnyomására megjelenik egy input box amellett a commit mellett ahonnan a branch-et leágaztatjuk. <br>
:[[File:ClipCapIt-191114-210342.PNG]]
A fenti képen látható, hogy létrehoztam a '''branch1''' nevű branch-et a 'Merge remote tracking branch..' nevű commit-ból. Az új branch-et automatikusan checkout-olta a GitKraken. Ezt a baloldalon láthatjuk a 'LOCAL' szekcióban. A master fölött (a korábbi branch) zöld pipával szerepel a '''branch1'''. A commit tree-ben a branch1 név mellett egy +1 szerepel, ami azt jelenti, hogy egy másik lokális branch-nek is ide mutat a head-je. Ha fölé visszük az egeret láthatjuk, hogy a másik lokális branch a '''master'''.<br>
:[[File:ClipCapIt-191114-210845.PNG]]
A branch neve mellette kis számítógép jelzi, hogy ezek a lokális branch head-ek.
<br>
Ha commit-álunk egyet az új lokális branch-en, akkor láthatjuk, hogy a korábbi master (amiből kiindultunk) és az új branch1 head mutatója már egyel eltérnek egymástól:
:[[File:ClipCapIt-191116-095109.PNG]]
 
Az is látszik a képen, hogy a '''branch1''' még a távoli repóban nem létezik, mert csak zöld kis számítógépes ikonja van. A master branch is egy commit-al előrébb jár mint a távoli master. <br>
A push megnyomásával juttathatjuk fel a lokális '''branch1'''-et a távoli repo-ba. Ekkor rá fog kérdezni, hogy mi legyen a távoli repo-ban a neve:
:[[File:ClipCapIt-191114-212356.PNG|750px]]
<br>
<br>
A push után láthatjuk, hogy a 'REMOTE' szekcióban is megjelent a 'branch1' és hogy a commit tree-ben a kis compute mellett megjelent a remote repo-t jelző kis zöld ikon is:
:[[File:ClipCapIt-191114-212833.PNG]]
A branch1 mellette kis pipa jelzi, hogy jelenleg a 'branch1' van check-out-olva.
<br>
<br>
===Váltás===
{{note|A --merged azokat is mutatja, akiknek a mutatója pont arra a commit-ra mutat, ahol most állunk}}
 == Merge ==
Mindig úgy kezdjük a merge-t hogy beleállunk abba a branch-be, AHOVA mergelni akarunk, majd kiadjuk a '''merge <branch neve AHONNAN>''' parancsot.
</pre>
Kétféle merge létezik:
1. Egy szülős (Kétféle merge létezik:  ===Fast-forward)merge===
Ebben az esetben az a branch, ahonnan mergelni akarunk egyenes ági leszármazottja a jelenlegi branch-nek. Az alábbi ábrán pl a '''hotfix'''-et ha mergeljük a '''master''' -be.
:[[File:ClipCapIt-160930-152407.PNG|500px]]
Ebben az esetben a git nem csinál mást, mint előre mozgatja a master mutatóját (fast-forward). Persze ha volt változás, akkor a változásokat elsőként egyesíteni kell és az esetleges konfliktusokat feloldani.
2. ===Két szülős, 3 utas===
Ebben az esetben az a branch ahonnan másolni akarunk (iss53), már nem közvetlen leszármazottja annak a branch-nek ahova merge-ni szeretnénk (master).
:[[File:ClipCapIt-160930-165652.PNG|500px]]
Ebben az esetben nem lehet egyszerűen előre mozgatni a mutatót. A git meg fogja keresni a közös őst, és egy három utas egyesítést fog csinálni a közös ősből, a jelenlegi branch -ből (a példában a master) és a bemásolandó branch-böl (a példában az iss53), és ebből az egészből létre fog hozni egy új commit-ot.
A mi példánkban a c6 lesz létrehozva a c5 c4 és c2 commit-okból.
:[[File:ClipCapIt-160930-170846.PNG|500px]]<br>Fontos, hogy az új merge commit elkészítéséhez a közös őst is felhasználja a git. Ez azért kell, hogy lássa hogy azon fájlokban ami mind a két ágon módosult, mi volt a kiindulási alap. Ha pl. az egyik ágon az első sort töröltem, a másik ágon az utolsót, akkor látni fogja az eredeti alapján, hogy nem az egész fájl változott csak az első és az utolsó sor, ez alapján el tudj készíteni az egyesített verziót.
<br><br>
===Merge GitKraken-ben===
 
 
<br>
<br>
 
 
==Rebase==
.... TODO ....
</pre>
:[[File:ClipCapIt-160930-155206.PNG|1000px]]
Ha becsukjuk a meld-et, akkor rá fog kérdezni, hogy sikeres volt e a merege:
[master bb194c8] mege után
</pre>
 
 
=Diff megértése=
 
..TODO..
:[[File:ClipCapIt-191113-195623.PNG]]
 
<br>
<br>
=Stash=
* transitive verb: to store in a usually secret place for future use —often used with away
* noun: something stored or hidden away
<br>
<br>
 
=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>
* [new tag] v1.4 -> v1.4
</pre>
 
=Rapid SVN=
 
==Új BitBucket repo klónozása==
A SmartGit sok féle GIT szolgáltató integrációját tartalmazza. Lehetőség van rá, hogy egy Git szolgáltatót mint pl a BitBucket felvegyünk mint '''Host Provider''', ami később lehető teszi, hogy klónozásnál egyszerűen válogathatunk az elérhető repók listájából anélkül, hogy tudnánk mi az adott repo clone URL-je. Fel fogunk venni egy BitBucket szolgáltatót.
 
<br>
Állítsuk be, hogy ne legyen SSL verifikáckó. Ezt a saját user-ünk alatt kell futtatni:
<pre>
$ git config --global http.sslVerify false
</pre>
 
 
Válasszuk a Repository -> Clone lehetőséget.
:[[File:ClipCapIt-190408-185336.PNG]]
Kattintsunk a '''Repository URL''' melletti mező kis fekete nyílra, majd válasszuk az '''Add hosting provider''' lehetőséget.
 
Itt válasszuk a BitBucket server (Atlassian Stash) lehetőséget.
:[[File:ClipCapIt-190408-185515.PNG]]
 
Adjuk meg a felhasználó nevünket és a jelszót, és a szerver base URL-jét, vagyis csak a hoszt nevet és a portot (ha nem szabványos a port):
:[[File:ClipCapIt-190408-190141.PNG]]
 
 
Ekkor be fog jelentkezni a SmartGit a Bitbucket-be és az összes projektet ki fogja listázni, amihez van hozzáférésünk:
:[[File:ClipCapIt-190408-190332.PNG]]
Nincs más dolgunk, mint hogy kiválasszuk a szükséges repo-t a listáról.
 
A jövőben ez a BitBucket provider azonnal elérhető lesz, nem lesz rá szükség hogy a szerveren kiválasszuk hogy mit akarunk klónozni, csak a Repository URL melletti kis fekete nyílra kell kattintani, és a lenyíló listában a BitBucket server-t kell választani, és a megnyíló ablakban már válogathatunk az elérhető repository-k között.
:[[File:ClipCapIt-190408-190521.PNG]]
 
 
A következő oldalon adjuk meg a felhasználó nevet és a jelszót:
:[[File:ClipCapIt-190408-190927.PNG]]
 
Válasszuk ki, hogy mit akarunk checkout-olni a kezdésként:
:[[File:ClipCapIt-190408-190955.PNG]]
 
 
Majd válasszuk ki a lokális mappát a repositroy-nak. A SmartGit a korábbi választásaink alapján általában tökéletes ajánlatot fog adni:
:[[File:ClipCapIt-190408-191114.PNG]]
 
 
 
<br>
A már felvett Hosting Provider-ek listáját megtekinthetjük az '''Edit -> Preferences -> Hosting Providers''' menüpont alatt:
:[[File:ClipCapIt-190408-191224.PNG]]
 
==Felület bemutatása==
 
===Branch-ek kezelése===
Az oldal tején láthatjuk a repository választót.
:[[File:ClipCapIt-190320-143706.PNG]]
Egyszerre mindig csak egy repository lehet kiválasztva, amin éppen dolgozunk. Nem lehet úgy repository-t váltani, hogy van módosított fájl a munkaterületen.
<br><br>
 
Az '''origin''' mutatja a távoli repository-t a '''Local Branches''' mutatja a helyi branch-eket. Az a lokális ág van jelenleg checkout-olva, amire a kis fekete nyíl mutat. ('''>''')
:[[File:ClipCapIt-190320-142231.PNG]]
Egyszerre mindig csak egy aktív branch lehet kiválasztva, amin éppen dolgozunk. Nem lehet úgy branch-et váltani, ha van módosított fájl a munkaterületen.
<br><br>
 
A képernyő alján láthatjuk az aktuálisan checkout-olt branchen hogy hol tart a HEAD pointer a lokális és a távoli repository-ban.
:[[File:ClipCapIt-190320-163431.PNG]]
A sárga (origin) mutatja, hogy a távoli repository hol tart, és a zöld mutatja, hogy a lokális változatunkban hol tart a HEAD pointer. A zöld mezőbe bele van írva a branch neve is (a példában develop). Ha a sárga és a zöld mező egybe esik, akkor a lokális repoban ugyan az van mint a központiban. A távoli állapotot a rapidSVN onnan tudja (sárga mező) hogy nem PULL-ozta csak FETCH-elte a távoli tartalmat, vagyis anélkül hogy letöltötte volna a lokális repoba a változást, csak lekérdezte, hogy mi változott. A rapidSVN periodikusan magától is futtat FATCH-t.
 
<br><br>
 
==Új branch létrehozása==
 
===Lokális branch létrehozása===
Új branch létrehozásához checkout-oljuk azt a lokális branch-et amiből le akarunk ágazni, majd a fenti menüből válasszuk a Branch -> Add Branch lehetőséget.
:[[File:ClipCapIt-190322-112604.PNG]]
Adjuk meg az új branch nevét, és válasszuk az "Add branch and checkout" lehetőséget. Ekkor lokálisan létrejön az új branch-ünk, ami checkout-olva is van. A távoli repóban (origin) ez a branch még nem létezik.
<br>
<br>
Kattintsunk az új lokális branch-re és nézzük meg a log-ját:
:[[File:ClipCapIt-190322-113111.PNG]]
<br><br>
Az új branch-et a develop ágból hoztuk létre. Láthatjuk, hogy a HEAD-je egybe esik a develop ág HEAD-jével. Azoban az új branchnek (Sprint6-swagger-planning) nincs megfelelője a távoli repóban (sárga origin), mivel ez még csak egy lokális branch, ezt PUSH-olni kell hogy a távoliban is megjelenjen.
:[[File:ClipCapIt-190322-113018.PNG]]
<br><br>
 
A fő képernyő alján, ahol az aktuálisan checkout-olt branch commit log-ját mutatja, láthatjuk, hogy a branch még csak lokálisan létezik, ezt jelzi a narancssárga vonal.
:[[File:ClipCapIt-190322-133941.PNG]]
 
 
<br><br>
 
===Lokális branch PUSH-olása===
A lokális branch-et PUSH-olni kell a távoli branch-be. Jobb klikk a lokális branch-re, majd PUSH.
:[[File:ClipCapIt-190322-141328.PNG]]
 
<br><br>
Ekkor a fő képernyőn lévő log historyban, ami az aktuálisan checkout-olt branch-et mutatja, a távoli sárga és a lokális zöld címke egy vonalba került, ezzel jelezve, hogy a lokális és a távoli branch már azonos.
:[[File:ClipCapIt-190322-141614.PNG]]
 
 
 
 
<br>
<br>
Miután már bármit PUSH-oltunk az új branch-be, a log-ban látszik, hogy már külön életet él a develop-hoz képest:
:[[File:ClipCapIt-190322-151513.PNG]]
A képen látható hogy a SPRINT6-swagger-planning branchben a lokális és a távoli ugyan azon a HEAD verzión van, mert a sárga és a zöld címke egybe esik. Azt is láthatjuk, hogy a pirossal jelölt develop ágban a lokális repónk le van maradva, mert a zöld lokális HEAD-et már több commit-al megelőzi a sárga távoli HEAD muató.
 
 
 
<br>
<br>
==Pull Request-ek kezelése (BitBucket)==
 
* '''Incoming pull''': requests are those which other users are requesting to pull from their repositories. They are displayed in a separate category called Pull Requests in the Branches view.
* '''Outgoing pull''': requests are those which you have sent to other users/repositories, requesting them to pull your changes. They are display directly below the local (or if it does not exist), the remote branch in the Branches view.
 
 
=== Pull request készítése===
 
 
 
=== Pull request megtekintése===
Checkout-olni kell azt a branch-et (vagy a master-t) aminek a pull request-jeit meg akarjuk nézni.
:[[File:ClipCapIt-190409-103758.PNG]]
Láthatjuk, hogy a SmartGit jelzi is, hogy a master ágon vannak Pull request-ek.
 
 
A megnyíló log ablakban láthatjuk, hogy a PULL request-ek külön vannak gyűjtve. A példában 11 pull request van. Ahhoz hogy meg tudjuk tekinteni a PULL request tartalmát és az arra adott comment-eket, vagy hogy mi is commentelni tudjunk, le kell Fetch-elni kell a pull requestet. Kattintsunk rá a megtekinteni kívánt pull request nevére, majd válasszuk a '''Fetch pull request''' lehetőséget.
:[[File:ClipCapIt-190409-103637.PNG]]
Ekkor a már lehozott pull request előtt meg fog jelenni egy Checkbox, ezzel jelezve, hogy már hozzá tudjuk adni ill ki tudjuk szedni az egyesített log nézetből.
 
 
Ha be van pipálva a checkbox a már lehozott (Fetch-elt) pull request sorában, akkor az külön megjelenik az egyesített log fában:
:[[File:ClipCapIt-190409-104237.PNG]]
Ha volt hozzá komment is, akkor egy narancssárga kis buborék jelenik meg a neve mellett.
 
 
 
Válasszuk ki az egyesített log fában a pull request sorát:
:[[File:ClipCapIt-190409-104724.PNG]]
 
Ekkor a bal oldali fájl listázóban meg fognak jelenni a Pull request-hez tartozó fájlok:
:[[File:ClipCapIt-190409-105525.PNG]]
A narancssárga buborék jelzi, hogy az adott fájlhoz van comment.
 
 
Ha kiválasztunk egy fájlt, akkor az kommentekkel együtt meg fog jelenni a bal alsó ablakban:
:[[File:ClipCapIt-190409-105828.PNG]]
 
 
A kommentekre lehet válaszolni, vagy a fájl tetszőleges pontjára új comment-et beszúrni.
Ha válaszolni akarunk, akkor jobb click a kommentre, majd Replay comment:
:[[File:ClipCapIt-190409-110146.PNG]]
 
 
A megnyíló ablak ki lesz már eleve töltve az eredeti comment tartalmával, amire válaszolni akarunk. Ezt töröljük ki és írjuk be a felső mezőbe a választ:
:[[File:ClipCapIt-190409-110341.PNG]]
 
A válasz meg fog jelenni az eredeti comment alatt:
:[[File:ClipCapIt-190409-110507.PNG]]
 
<br>
<br>
<br>
 
===Pull request frissítése===
Ha egy commentezett pull request-ünket frissíteni akarunk, akkor nincs más dolgunk, mint hogy ugyan arra a branch-re PUSH-oljuk be ugyan azokat a fájlokat módosítva, amire a PULL request volt kérve. Ekkor a bitBucket észre fogja venni, és frissíteni fogja az eredeti request-et.
Ha a PUSH után megnyitjuk a LOG-ját a repository-nak, akkor a pull request felsorolásban, látni fogjuk, hogy a lokális másolata a pull request-nek már elavult.
:[[File:ClipCapIt-190409-133002.PNG]]
 
 
Az egyesített log fában láthatjuk, hogy a branch-ünk már egyel előrébb jár mint a pull request:
:[[File:ClipCapIt-190409-133336.PNG]]
 
 
Külön frissíteni kell a pull request adatokat:
:[[File:ClipCapIt-190409-133704.PNG]]
 
 
Ekkor láthatjuk az egyesített log fában, hogy megint a pull request kerül a commit-unk elé:
:[[File:ClipCapIt-190409-133854.PNG]]
 
 
Innentől kezdve nem lehet megnézni az előző kommenteket.
 
A bitbucket-ben látható, hogy mind a két commit-ot hozzákapcsolta az eredeti pull request-hez:
:[[File:ClipCapIt-190409-134117.PNG]]
 
<br>
<br>
 
=== Pull request elfogadása===
 
<br>
<br>
 
==Merge feature branch to master ==
Ha van egy branch-ünk amit egy másik branch tetejére akarunk rakni (tipikusan egy feature branch-et a develop-ra vagy master-re, akkor elsőként inden lokális változtatást push-olni kell a távoli szerverre, majd bele kell állni (checkout) abba az ágba, ahova merge-ölni akarjuk a feature branch-et, az esetünkben ez a develop branch lesz.
 
Nyissuk meg a log fát a develop ágon (jobb click -> logs). A bal oldali pipálós listában pipáljuk be azt a branch-et, amit mergelni szeretnénk a developre. Majd az egyesített log fában keressük meg. Mivel a develop-ban állunk, egy még nem merge-ölt feature branch vége a levegőben fog lógni:
:[[File:ClipCapIt-190415-174834.PNG]]
Kattintsunk rá, hogy legyen kijelölve.
<br>
Ez után válasszuk a felső fő menüben a Merge lehetőséget. Ekkor a felugró ablakban szövegesen is ki lesz írva, hogy mit hova akarunk merge-ölni.
:[[File:ClipCapIt-190415-175222.PNG]]
Két lehetőségünk van:
* Azonnal készítünk az egyesített állapotból egy úgynevezett merge-commit-ot. Ezt akkor tehetjük meg ha nincs conflict.
* Csak a munkaterületre merge-öli rá a smartGit a feature branch-et, és majd mi végezzük el a commit-ot miután feloldottuk a konfliktust.
<br>
Általában az első lehetőség megfelelő. Ez után láthatjuk majd, hogy a fő képernyőn a branch history-ban, hogy a lokális reponk megelőzi a távoli head-et.
:[[File:ClipCapIt-190415-175543.PNG]]
Azt is láthatjuk, hogy automatikusan adott commit üzenetet a smartGit: "Merge remote-tracking branch 'origin/XXXX' into develop".
 
Most ha nyomunk egy PUSH-t, akkor fel is fogja küldeni az origin-ba az új merge-commit-ot.

Navigation menu