Szerkesztő:Madbence/Git tutorial

A VIK Wikiből
< Szerkesztő:Madbence
A lap korábbi változatát látod, amilyen Madbence (vitalap | szerkesztései) 2013. január 20., 01:26-kor történt szerkesztése után volt. (Új oldal, tartalma: „==Leírás== A Git egy elosztott verziókezelő rendszer, tehát SVN-nel (és társaival) ellentétben nem egy központi szerveren van meg minden fájl, hanem mindenhol…”)
(eltér) ← Régebbi változat | Aktuális változat (eltér) | Újabb változat→ (eltér)
Ugrás a navigációhoz Ugrás a kereséshez

Leírás

A Git egy elosztott verziókezelő rendszer, tehát SVN-nel (és társaival) ellentétben nem egy központi szerveren van meg minden fájl, hanem mindenhol elérhető a teljes repó. Rengeteg git parancs van, én csak a legfontosabbakat írom le (minden platformra van GUI is hozzá, nekem ezek nem túl szimpatikusak, sokkal hatékonyabb parancssorból buzgerálni mindent)

Kezdés

Üres repó létrehozása:

$ git init

Ez annyira nem izgalmas, egy létező repót lekérni annál inkább:

$ git clone https://foo.bar/baz.git

Ez a parancs az aktuális könyvtárban csinál egy baz mappát, oda pedig mindent szépen letölt.

Kultúráltak vagyunk, úgyhogy konfigoljuk be a gitet:

$ git config --global user.name "Gipsz Jakab"
$ git config --global user.email gipsz@jakab.com

Aki nem szereti a vim editort, az beállíthajta, mivel szeretné a commitokat szerkeszteni:

$ git config --global core.editor emacs

Emacs helyett persze mást is lehet én notepad++-t szoktam használni (ha panaszkodik az elérési útra windowson, akkor az idézőjelekkel kell babrálni: "'C:/npp/npp.exe' -multiInst -nosession")

Hozzáadás

Ha csinálunk egy új fájlt/mappát, az alapból nem lesz verziókezelve, ez meg is nézhetjük a status parancs segítségével:

$ touch README
$ git status
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       README
nothing added to commit but untracked files present (use "git add" to track)

A git le is lövi a poént, az add parancs fájlokat/mappákat ad hozzá a következő commithoz (akárhányat)

$ git add README

Mostmár a rendszer látja a fájlt, de még nincs benne a repóban, committolni kell.

$ git status
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#       new file:   README

Ezt a commit parancs el is végzi nekünk...

$ git commit

Nagyon fontos dolgunk van, mégpedig írni egy commit üzenetet. Fontos, hogy világos, érthető legyen, később is lehessen tudni, miért történt az a változtatás. Ha nem tetszik az alap szövegszerkesztő, akkor be tudunk állítani sajátot, vagy rögtön a parancs mellet az -m kapcsolóval meg is írhatjuk az üzenetet.

$ git commit -m "Initial commit"

Nem kell mindig egyesével hozzáadni a commithoz a fájlokat, az -a kapcsoló automatikusan minden változást bevesz (az új fájlokat még mindig nekünk kell fölvenni!) Ha nem vagyunk biztosak benne, mi kerül a commitba, a --verbose kapcsoló a commit üzenet megadásakor az egész diffet berakja (diff=előző és mostani változat közötti különbség)

Elkúrás

Mi van, ha elkúrtam az üzenetet, és már commitoltam? Semmi gond, lehet szerkeszteni:

$ git commit --amend

Az -m kapcsoló használható természetesen.

Mi van, ha szar az egész commit? A reset pont jól fog jönni:

$ git reset --soft HEAD~

Kis magyarázat. A commitok jönnek szép sorban, az utolsó commit az ágon a HEAD, a ~ jel a HEAD szülője lesz (~2 nagyszülő, satöbbi)

A --soft kapcsoló pedig azt fogja csinálni, hogy csak a HEAD mutatót helyezi át. Nem fog fájlokat módosítani, nem bántja a fájlokat, amiket hozzáadtunk a commithoz (add)

Kicsit drasztikusabb változat:

$ git reset --mixed HEAD~

Ez megcsinálja ugyanazt, mint a --soft, de a commithoz hozzáadott fájlokat (hívjuk indexnek ezután) is visszaállítja a mutatott commitra. Ha nem adunk meg a resetnek semmilyen kapcsolót, akkor ezt csinálja alapból.

Még félelmetesebb a

$ git reset --hard HEAD~

Ez mindent visszaállít, ténylegesen a fájlokat is! Szóval csak óvatosan.

Fejlesztési ágak

Eddig a commitok szép sorban jöttek egymás után, viszont nagyobb projecteknél ez nem igazán jó ötlet, célszerű a fejlesztést ágakra lebontani. Erre van megoldás a gitben:

$ git branch feature

A "feature" az ág neve, amit létrehozunk. A gyökere az aktuális commit. De még nem használjuk, szóval ezt is meg kell mondani:

$ git checkout feature

Ezzel elhagyjuk az eredeti fejlesztési ágat (alapból a fő ág a "master"), és átlépünk a "feature" ágra. Itt commitolhatunk kedvünkre, satöbbi. Sőt, még további ágakat is létrehozhatunk. Ha egy kicsit elvesztünk, hogy most milyen ágon is vagyunk, akkor simán a git branch megmondja egyrészt milyen ágaink vannak, másrészt megmondja melyiken is vagyunk (csillag van a neve előtt)

Ha kész a fícsör lefejlesztése, szeretnénk visszavezetni a főágba a változásokat. Erre lesz jó a félelmetes merge:

$ git checkout master
$ git merge feature
$ git branch -D feature

Először visszaváltunk a főágra. Aztán összeolvasztjuk a két ágat. Majd töröljük a feature ágat. Sajnos irtkán ilyen szép az élet, néha a git nem tudja magától megmondani, hogy mit honnan szedjen, többen szerkesztették ugyanazt a fájlt. Ilyenkor conflict van. Ezeket manuálisan kézzel kell kijavítani, elmenteni a fájlokat, majd commitolni manuálisan (a merge ugyanis egy commit).

Ha nagy mázlink van, és a master ágon senki sem fejlesztett, amíg mi a branchon bűvészkedtünk, akkor a merge helyett fast-forward történik, a head egyszerűen előreugrik (képzeljétek el az ágakat, mint függőleges vonalak, a commitok bogyók, elég jól lehet látni, miért is lehet ezt megtenni). Szóval ennek örülünk :)

Remote

Távoli repóba is jó, ha mentünk, ilyeneket tud a github vagy a bitbucket.

Ha esetleg nem klónoztuk volna a repót, hanem initet használtunk, akkor hozzá kell adni a távoli repót a remote paranccsal:

$ git remote add origin https://foo.bar/baz.git

Az add hozzáad, az origin a neve, így fogjuk hívni ezután. Tiszta sor.

Le szeretnénk kérni a repó aktuális változatát:

$ git fetch

Ha több távoli repónk is van, akkor oda lehet írni a nevét is (alapból origin-nak hívják)

Ha szeretnénk az eddigi commitokat fenyomni a szerverre:

$ git push

Nagyon sok szót nem is pazarolnék rá.

Hogy is volt?

Már mindent tudunk a gitről, csak azt nem, hogy hogyan is tudjuk visszanézni, mit csináltunk. Ezt többnyire a log parancs tudja szépen megmutatni:

$ git log

Kb mindent ki lehet vele deríteni, az -n kapcsoló a bejegyzések számát limitálja, a --since="2 weeks ago" az utolsó két hét commitjait mutatja, ha egy fájlnevet adunk meg a végén, akkor csak a rá vonatkozó commitok jelennek meg (ugyanez mappanév/ változattal mappára), az -S'foo()' azokat a commitokat jeleníti meg, amiben benne volt (eltűnt/megjelent) a foo(), --stat megmutatja mennyi sor változott.

Formázni is lehet, a --pretty=online pl egysoros változatban nyomja ki.

Kismillió kapcsolója van, itt meg lehet találni mindet: http://linux.die.net/man/1/git-log

A --graph grafikusan is megjeleníti a fejlesztési ágakat. Itt egy példa:

$ git log --graph --oneline --date-order
* b450119 partial
*   39d69f0 Merge branch 'exp'
|\
* \   2bf5367 Merge branch 'exp2'
|\ \
* | | ab5a665 6
| * | 369d10b fb2
| * | 6db3ec6 fb1
| | * 0d726e6 fa4
| | * 5064725 fa3
| |/
| * 542c972 fa2
| * ad88635 fa1
|/
* d14df30 5
* be70310 4
*   21bb204 Merge branch 'feature'
|\
* | b911d4f third
| * 5e6acf2 feature6
| * 577f064 feature5
|/
* 37b0e0f feature4
* 662833a feature3

Utoljára maradt a blame, ami sorran lebontva jeleníti meg egy fájl utolsó szerkesztőit:

$ git blame file

Hasznos, ha tudni akarjuk ki kúrta el a fájlt :)

Megjegyzés

Az írás 2012 elejéről származik, azóta kicsit jobban belemélyedtem a gitbe, de szerintem a leírás még használható. lennon (vita) 2013. január 20., 02:26 (CET)