alapok dokumentáció git bash git add git branch git checkout git cherry-pick git clean git clone git commit git config git diff git fetch git help git init

git log git ls-tree git merge git pull git push git rebase git remote git reset git revert git rm git stash git status git tag .gitignore gitlab.com

hook példák repository smartgit

• Nagyon fontos hogy a git használata előtt elvégezzük ezeket a beállításokat!
• A "git config --global" beállítások a gépen lévő összes git-re vonatkoznak, akár parancssoros, akár Netbeans-es, de csak a bejelentkezett user-re érvényes!
• A sorvég karakterek oda-vissza konvertálásának letiltása:
• Személyes adatok beállítása, melyek a repository-ban tárolódnak a commit-ok során:
• Https és ssh protokollok esetén ne figyelje a tanúsítványokat:

• Alap dokumentáció
  
• A successful Git branching model
• Git Cheatsheet

• A Git Bash egy parancssoros felület, mely minden platformon fut: innen telepíthető
• MacOS-en a telepítés után rakjuk be a $PATH-ba a /usr/local/git/bin -t, mivel ide települ.

• git commit előtt azokat a fájlokat melyeket szeretnénk a commit-tal eltárolni a repository-ba, egy git add-dal kell megjelölni.
• A legjobb módszer mellyel az összes fájlt bejelöljük az aktuális könyvtárban(.) és alkönyvtáraiban,
  de eltávolítjuk az indexből ami régebben már benne volt, de már nem létezik a fájlrendszerben:
• Például ha konkrét fájlokat szeretnénk így megjelölni akkor:

• Branch-ek lekérdezése
  Az aktuális *-gal van jelölve: A branch-ek lekérdezése nem biztos hogy jól mutatja a távoli branch-eket, ugyanis mutathat olyat branch-et is ami már törölve lett.
  Ennek a hamis információnak a frissítése valósra, például a távoli "origin" repository frissítése:
• Branch létrehozása
  A branch létrehozása után még nem ez lesz az aktuális. Addig nem mutat ide a HEAD amíg egy checkout-ot nem csinálunk.
• Branch törlése
  Csak akkor törölhető ha nem az aktuális branch.
  Ezzel a módszerrel az is elérhető hogy lokálisan ne legyen meg a branch(pointer), csak a remote repository-ban.
  Így ha ezzel az ággal nem kell dolgozni, nem lesz zavaró.
  A branch törlése a távoli repository-ban:
• Branch átnevezése
  Ezzel csak a lokális branch kerül átnevezésre, a távoli repository-n lévő branch név nem változik.
  A régi branch törlése a távoli repository-ban:
• Branch track
  Mivel a pull nem hozza létre lokálisan a branch-eket, ha lokálisan létre akarjuk hozni (a távoli másolataként), akkor ez kell például: Másik módszerrel is lehetséges a branch track:

• Repository-ban lévő állapot visszaállítása workdir-be.
  Ha a checkout egy teljes commit-ra vonatkozik (nem pedig egy-egy fájlra) akkor a HEAD is ide áll be.
• A checkout művelet a workdir-ben lévő untracked fájlokat nem változtatja meg (ha nincs ilyen a visszaállítandó commit-ban).
• A checkout művelet a workdir-ben lévő tracked fájlokat megváltoztatja, és a visszaállítandó commit-nak megfelelőek lesznek.
  Ha például a workdir tartalmaz egy tracked a.txt fájlt, a visszaállítandó commit viszont nem tartalmaz, akkor a workdir-ből a fájl törlődik.
• Például egy másik branch-ben lévő állapot visszaállítása:
• Új branch létrehozása, és ennek checkout-ja is egyben:
• Ha egy tetszőleges commit-ra akarunk visszaállni (egy branch közepén) akkor 2 eset lehetséges:
  • Csak meg akarjuk nézni a workdir-t de biztos nem fejlesztjük tovább ezt az állapotot. Ezt azért fontos tudni, mert ilyenkor egy branch nélküli állapotban leszünk, ahol nem szabad commit-álni. Például:
  • Ezzel az állapottal folytatjuk tovább a fejlesztést a workdir-ben, és későbbiekben commit-álunk is ebből. Ekkor a checkout-tal együtt egy új branch-et is létre kell hoznunk pl:
• Példák fájl(ok) illetve könyvtár checkout-ra. Ilyenkor a HEAD nem változik, csak a workdir módosul:

• Ágak összevonása a merge-hez hasonlóan, de itt máshogy épülnek fel az új commit-ok.
  Az átláthatóság, és megbízhatóság miatt inkább merge-t használjunk !

• Untracked állapotú fájlok/könyvtárak törlése a workdir-ből. A -d kapcsolóval lehet törölni untracked könyvtárakat is.
• Példák:

• Repository klónozása (másolása).
• A --bare kapcsolóval bare-repository, nélküle non-bare repository készíthető.
• Például a /Users/xesj/vcs könyvtárban lévő non-bare repository-ról egy bare-repository másolat készítése vcsbare.git néven a /tmp könyvtárban:
• Például a /tmp/vcsbare.git bare-repository-ról egy non-bare repository készítése a /Users/xesj/vcs könyvtárba:
• Például bare-repository készítése ssh-elérésű távoli serveren.
  Előszőr csak a lokális gépen lehet a bare-repositoryt létrehozni, majd ezt kell felmásolni a távoli serverre: Ha távoli serveren lévő bare-repositoryt meg szeretnénk osztani másokkal, akkor lépjünk be a repository könyvtárába, majd adjuk ki a következő parancsot:
• Például non-bare repository készítése a lokális gépen a mydir könyvtárban, ssh-elérésű távoli serveren lévő bare-repository alapján:

• Workdir-ben lévő fájlok tárolása a repository-ba.
• Például tárolás az itt megadott megjegyzéssel, és előtte hozzáadjuk a commit-álandó fájlokat:
• Például nem jó az utolsó commit.
  Ekkor a workdir-ben a hibát javítva, nem egy új commit-ot kell létrehozni hanem az előzőt javítani:

• A beállítások lehetnek globálisak ha a --global kapcsolót használjuk, lehetnek rendszer beállítások a --system kapcsolóval, ezek nélkül a beállítások lokálisak. Például:
• A jelenlegi beállítások megtekintése, például:
• Törli a git által megjegyzett összes repository-hoz tartozó jelszót:

• Fájlok összehasonlítására szolgál. Akár két különböző branch egy-egy commit-ját is össze lehet hasonlítani.
• Például az aktuális változások a workdirben az utolsó commit-hoz képest:
• Például 2 branch (utolsó commit-jának) összehasonlítása:
• Például 2 commit összehasonlítása:
• Például 2 commit-ban egy adott fájl összehasonlítása:

• A lokális repository frissítése a távoli repository alapján.
  • Bármikor végrehajtható, nem okoz problémát, akkor sem ha még nincs commit-álva a working directory
  • Nem hajt végre merge műveletet
  • Nem módosítja a working directory-t
  • Nem módosítja a HEAD-et
  • Ha a távoli repository-ban olyan branch található ami a lokális repository-ban nincs, akkor létrehozza, a többi létező branch-hez pedig hozzáfűzi az új commit-okat.
• Az összes branch frissítése:
• Csak egyetlen branch (pl: "develop") frissítése:

• Információ a git parancsokról.

• Ezzel a paranccsal egy adott könyvtárban állva, létrehozhatjuk a könyvtárhoz tartozó üres non-bare repository-t. A könyvtárban létrejön egy rejtett ".git" alkönyvtár. Ha a könyvtárban fájlok is voltak akkor azok "untracked" állapotúak lesznek, vagyis a git figyelmen kívül hagyja őket a műveleteknél.

• Információ kérése az eddigi commit-okról:
• Megjeleníti az elágazásokat, ha már volt merge ezen az ágon:
• Csak a commit kódok, és a hozzátartozó megjegyzések egy-egy sorban:
• Tag nevek megjelenítése:

• Fájlok listája egy adott commit-verzióban, pl: a 36eb9c... -ben:

• Ágak összevonása. Az aktuális ágba beolvasztja a paraméterében megadott másik ágat, vagy az ág egy commit-ját.
• Például a másik_branch beolvasztása az aktuális branch-be:
• Például egy másik branch egy adott commit-jának beolvasztása az aktuális branch-be:
• Ha az összevonás konfliktus mentesen automatikusan végrehajtható, akkor egy új commit-ot is csinál. Az új commit-nak 2 szülője lesz, így a git log-ban mindkét ág commit-jai megjelennek.
• Ha az összevonáskor nem tudja feloldani a konfliktusokat, akkor nem készít commit-ot. A konfliktusos fájl(ok)ba belerakja mindkét lehetőséget, melyet nekünk kell manuálisan javítani (az egyik lehetőséget kitörölni) hogy végre lehessen hajtani commit-ot:

• Távoli serveren lévő repository egy ágának (branch) tárolása a lokális repository-ba, és merge készítése ha szükség van rá.
• Csak azt az ágat pull-oljuk amelyik az aktuális !
  Különben az aktuális ág megváltozhat, mivel a pull erre az ágra rakja rá a távoli ág commit-jait !
• Például:
• A pull nem az összes fájlt tölti le, hanem csak azokat melyek megváltoztak. Így tekinthető meg mi fog letöltődni:

• Lokális repository egy vagy több branch-ének tárolása távoli serveren.
• Például a develop branch tárolása, ahol a távoli servert url-lel adjuk meg:
• Például a develop branch tárolása, ahol a távoli servert logikai névvel adjuk meg: (Előtte szükséges a logikai nevet definiálni például: git remote add origin ssh://xesj@remoteserver/Users/xesj/bare/vcs.bare)
• Ha a git reset paranccsal visszaléptünk a lokális repository-ban, és ezt a visszalépést szeretnénk érvényesíteni a távoli repository-ban is, akkor a -f kapcsolót kell használni, például a develop ág visszaléptetése:

• Ágak összevonása a merge-hez hasonlóan, de itt máshogy épülnek fel az új commit-ok.
  Az átláthatóság, és megbízhatóság miatt inkább merge-t használjunk !

• Távoli serveren lévő repository-hoz logikai név definiálása, lekérdezése, átnevezése.
• Az eddig beállított logikai nevek lekérdezése:
• Például ssh-elérésű távoli serverhez logikai név (origin2) létrehozása:
• Például az origin2 logikai név törlése:
• Például a gitblit logikai név átnevezése origin-re:

• Commit-ok törlése !
  A HEAD-et visszaállítja arra a commit-ra amit megadtunk, ezért az utána következő commit-okra nincs hivatkozás, törlődni fognak.
• A --hard kapcsolót használva a workdir is változik, az új HEAD-nek megfelelő tartalmú lesz. Például:
• A --soft kapcsolót használva a workdir tartalmát nem változtatja meg. Például:
• Nem ajánlott a használata abban az esetben, amikor a távoli repository-ban már push-olva vannak a törlendő commit-ok, és már valakik pull-olták azokat. Ha mégis vissza akarjuk léptetni a távoli repository-t is, akkor mindenképp kell a -f kapcsoló a push-hoz:

• Készít egy új commit-ot, ami úgy néz ki, mintha az eddigi commit-okból kivenné azokat amit megadunk a paraméterében. Akkor hasznos, ha vissza akarunk állni egy régi commit-ra, de az új (nem kívánatos) commit-ok már push-olva vannak egy távoli repository-ba, így már más személy esetleg pull-olta őket.
• Tegyük fel hogy a commit lánc ilyen: Szeretnénk hogy létrejöjjön egy új c5jó commit, de az pont olyan legyen mint a c2jó. Tehát vissza kell vonni a c3rossz és c4rossz commit-okat: melynek eredménye:

• Track-elt fájlok áthelyezése untracked állapotba, így nem vesznek részt git műveletekben. A parancs a "git add" ellentéte.
• Például a.txt áthelyezése untracked állapotba:
• Például egy adott könyvtárban és alkönyvtáraiban lévő fájlok áthelyezése untracked állapotba:
• Például a.txt fájl törlése a workdir-ből:

• Visszaállítja a wordir-t a tiszta állapotba, vagyis ami a legutolsó HEAD commit-nál volt (csak a tracked fájlokkal foglalkozik).
  A workdir-ben lévő állapot megörződik egy stash-területen, melyre később ha szükséges visszaállhatunk.
• Workdir visszaállítása tiszta állapotba:
• Stash-területek listázása:
• Az összes stash-terület törlése:

• Egy adott non-bare repository könyvtárában kiadva a parancsot, státusz információt ad a fájlokról, és az aktuális branch-ről.

• A tagok segítségével egyes commit-okat külön fel lehet cimkézni, például a program verzióját írjuk a cimkére.
  A tagnév nem tartalmazhat szóközt.
• A tagok nagy előnye a commit message-ekkel szemben, hogy a tagok áthelyezhetők más commit-ra, illetve törölhetők.
• A legutolsó commit-hoz tag rendelése:
• Egy régebbi commit-hoz tag rendelése:
• Létező tag-ok listázása:
• Egy tag törlése, mely függetlenül attól melyik commit-hoz van rendelve:
• Egy tagnévhez rendelt commit információk megjelenítése:
• Ha már létező nevű tag-ot egy másik commit-hoz rendelünk, akkor ez az új commit lesz a tag-gel megjelölve, nem pedig a régi.
• Ha a lokális repository-ban töröltünk egy tagot, annak törlése a távoli repository-ból:

• A főkönyvtárban lévő .gitignore fájlban jelezhető melyek azok a fájlok melyeket a git ne vegyen figyelembe, vagyis untracked állapotban kell maradniuk.
• Azok a fájlok melyek a .gitignore bejegyzés előtt már tracked állapotban vannak azok úgy is fognak maradni, ekkor használható a git rm.
• Ha könyvtár nevet használunk azt / jellel fejezzük be.
• Ha egy sor #-kal kezdődik vagy üres, az figyelmen kívül marad.
• Példák arra hogy milyen bejegyzések milyen fájlokat zárnak ki (untracked állapotban hagynak):

• A gitlab.com webhelyhez nem kell SSH kulcsot készíteni. Ha nincs, akkor https protokollt fog ajánlani a project repository eléréséhez.
• Ha a projekt publikus, akkor felhasználónév nélküli url-lel is elérhető, például:
• Ha a projekt privát, akkor meg kell adni a felhasználónevet az url-ben: Ha erre az url-re egy git bash-ban hivatkozunk egy git clone parancsban, akkor a git bash egy popup ablakban kéri be a vendég jelszavát.
• A felhasználónéven kívül a jelszó is beleírható az url-be:

• Bizonyos git eseményekhez (commit, push) hozzárendelhető egy-egy shell script, mely a git esemény bekövetkezésekor lefut. Egy ilyen shell scriptet hook-nak nevezünk. Ezek lehetnek kliens és szerver oldaliak.
• A 3 szerver oldali hook közül a post-receive akkor fut, akkor már a git push lezajlott, és a szerver oldalon minden művelet megtörtént. Erre például írható olyan hook, ami a projekttel valamilyen műveletet végez. A post-receive nem kap kívülről paramétert, hanem a standard inputról kell beolvasnia a szükséges információkat. Ezek az információk space-szel vannak elválasztva: Általában a középső adatra van szükség, ez az új commit-id, ez alapján lehet kiolvasni hogy a fejlesztő milyen commit üzenetet írt. Egy jó ötlet, hogy a commit üzenetbe hook: kezdetű szöveget írjunk, ha azt szeretnénk, hogy a hook erre valamit csináljon, és azt csinálja amit odaírtunk.
• Példa egy szerver oldali post-receive hook-ra, melyet a szerver oldalon lévő git repository hooks könyvtárába kell elhelyezni post-receive névvel. Akkor fut le, amikor a project push-olva lett a szerverre, és figyeli hogy a commit üzenet hook: kezdetű-e, mert ezesetben a /tmp könyvtárban létrehoz egy fájlt a hook névvel:
• dokumentáció: server side hooks

• Egy "mydir" nevű könyvtárat szeretnénk git-tel verzókezelni. Be kell állni a "mydir" könyvtárba majd kiadni a következő parancsokat:

• Kétféle repository van: bare, és non-bare repository.
• Non-bare repository:
  Tartalmazza a repository adatbázist és a working directory-t (workdir). Ezzel a fajta repository-val dolgozunk a workdir-ben, majd tároljuk a változásokat a repository adatbázisba. A repository adatbázis a workdir-en belül van egy rejtett .git nevű könyvtárban.
• Bare repository:
  Nem tartalmaz working directory-t (workdir), csak a repository adatbázist. Ez a repository fajta szolgál arra hogy egy távoli serveren legyen és megosszuk mással. Általában egy önmagában álló könyvtár .git kiterjesztéssel, például: valami.git

• Az egyik legjobb git kliens, mely Java-ban íródott, így fut minden platformon. Azokat a repository-kat melyeket nem kezel egy speciális fejlesztőeszköz (pl. NetBeans), azt érdemes a SmartGit programmal kezelni: innen telepíthető