git tut

Miről szól ez a leírás?

A git nevű verziókövető rendszert mutatja be néhány példán keresztül. Nem tartalmaz minden trükköt, ez csak egy abszolút kezdőknek szóló gyors tutorial.
Parancssor vs. grafikus felület

A git-et elsősorban parancssorból érdemes használni windows alól is.

Az egyetlen értelmes grafikus felület a gittel való munka megkönnyítésére a gitk program, ami csupán megjelenítést végez (erre viszont érdemes gyakran használni). Igaz, hogy létezik a TortoiseGit, illetve a SmartGit nevű csoda, de ezek az előzetes tapasztalatok szerint nem a parancssori kliensnek megfelelően működnek. Mivel az összes létező tutorial, doksi a parancssori verzióhoz készült, ezért kezdőknek sokkal inkább ajánlott a gépelgetős megoldás. Akkor is, ha windows-os vagy, tényleg-tényleg-tényleg sokkal jobb lesz neked, ha a parancssort használod.
Telepítés, Linux

Debian disztribúcióknál az a trükk, hogy a git csomag az nem a git. Ha debian-t, vagy ubuntut használsz, akkor a git-core csomagot kell telepíteni. Erre a csomagra sok más dolog épül, így van például git-svn csomag is, ami azt ígéri, hogy vele együttműködhetsz SVN-es tárakkal is, de sajnos bizonyos verziói tele van bugokkal, így használata nagyon nem ajánlott.

A telepítés tehát egy egyszerű

# apt-get install git-core

paranccsal (vagy kedvenc apt frontendeddel, pl. synaptics-szal) megoldható.
Telepítés, Windows
Git telepítése

Window alatt használd az msysGit nevű teremtményt

Az msysGit több formában jön. Neked a “for end-users” verzió kell, ami legutóbb ezen az oldalon az első sor volt. Tehát nem a portable, vagy az “if you want to hack on git” verzió, hanem a másik.

A program egy sima windowsos telepítő, next, next, bár nem minden mindegy:

    *
      How would you like to use Git from the command line?
          o
            Use Git Bash only: Ekkor nem kerül be a git a pathba, így csak a git bashből tudjuk futtatni
          o
            Run Git from the Windows command prompt: Ekkor bekerül a pathba, szerintem az nem árt, én ezt választanám
          o
            Run Git and included Unix tools from the Windows Command Prompt: Ha ezt választjuk, akkor a pathba betesz egy csomó unixos utilityt, sajnos némelyik neve egyezik windowsos parancsokkal, tehát bekavarhat ha bat-ból vagy máshogy használnánk
    *
      Choosing the SSH executable
          o
            Use OpenSSH: Ezzel egyszerűbb a beállítás
          o
            Use (Tortoise)Plink: A Putty-t használja, ami pár dolgot be tud kavarni a kulcskezelésnél, de megoldható ezzel is
    *
      Choosing CR/LF behavior: Windowsos vagy unixos sortörést használjunk? Legjobb ha azt használjuk, hogy “Commit line endings as they are”, és vigyázunk rá, hogy az új fájlokat milyen sorvége-jelekkel hozzuk létre, ugyanis az automatikus konverziókkal mindig csak a baj van.

A Git parancssoros felületét elindíthatjuk a Start menüből, de akkor át kell mennünk a megfelelő könyvtárba (cd), hogy a repóinkkal foglalkozhassunk. Kényelmesebb, ha már előttünk van a könyvtár akár Intézőben, akár Total Commanderben, mert kattinthatunk jobb gombbal, és használhatjuk a Git Bash here pararancsot. Ekkor úgy indítja el, hogy már az adott könyvtárban vagyunk.
SSH kulcsok használata

Az SSH kulcspár azért hasznos, mert ha a szervernek megadjuk a pár nyilvános felét, akkor a titkos kulcsot használva be tudunk jelentkezni jelszó megadása nélkül. Mivel a szervert érintő git parancsok kiadásához SSH kapcsolatot nyitunk, kényelmetlen lenne minden alkalommal jelszót gépelni.
OpenSSH

Amennyiben a Git telepítésekor az OpenSSH-s módszert választottuk, parancssorból tudjuk generálni a titkos/nyilvános kulcspárunkat.

$ ssh-keygen -t rsa -C "[email protected]"
Generating public/private rsa key pair.
Enter file in which to save the key (C:/xxxxxxxx/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /c/xxxxxxxx/.ssh/id_rsa.
Your public key has been saved in /c/xxxxxxxx/.ssh/id_rsa.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx [email protected]

Fogadjuk el a default helyet nyugodtan. Jelszóval biztonságosabb, ha nem akarjuk beírogatni minden alkalommal, lehet használni pl. az ssh agentet, ami megjegyzi. Ha nem izgat minket, hogy jelszó nélkül mentjük el a merevlemezre a kulcsot, akkor hagyjuk üresen.

A saját felhasználói mappánk (C:\Documents and Settings\usernév) könyvtárba bekerült két fájl, az id_rsa (titkos kulcs) és az id_rsa.pub nevű (nyilvános kulcs). Most már csak azt kell közölni a szerverrel, hogy mi a nyilvános kulcsunk. Ehhez jelentkezzünk be (még jelszó használatával), és másoljuk fel a nyilvános kulcsot (id_rsa.pub) a szerverre .ssh/authorized_keys néven a home könyvtárunkba. Ha több helyről, több kulccsal szeretnénk bejelentkezni, akkor egyszerűen másoljuk össze ebbe a fájlba a kulcsokat (egy sor - egy kulcs)

Amikor egy szerverre először lépünk be, fel fogja ajánlani, hogy az ismert szerverek listájába betegye, ezt csak egyszer kell elfogadnunk.
Putty/Plink/TortoisePlink esetén

A folyamat kicsit más, ha a kapcsolódásra (Tortoise)Plinket használunk, ekkor a kulcsot a Puttygen nevű programmal tudjuk generálni (vagy az előbb leírt módon generált kulcsot átmenteni a putty .ppk formátumába. Ha ezt választottuk telepítéskor, akkor használnunk kell a Pageant programot is, amit elindítva majd abba a kulcsokat betöltve ugyanúgy fog működni, mint az OpenSSH-s módszer. Ezek a programok a Putty oldaláról tölthetők le.
Windowsos grafikus Git kliensek
TortoiseGit

Aki ismeri a Tortoise SVN-t, ahhoz nagyon hasonló felületet ad a TortoiseGit. Előbb az msysGitet kell telepíteni, ugyanis a TortoiseGit is azt használja. Ugyanúgy beépül az explorerbe, mint a TortoiseSVN, így a fájlok állapotát kis overlay ikonokkal jelzi.

    *
      A szerverre ajánlott először egyszer Putty-val bejelentkezni, így el tudjuk fogadni a szerver kulcsát, ezután nem lesz gond már ebből TortoiseGitben. (Ezt természetesen szerverenként egyszer kell csak megtenni)
    *
      Rebase-nél oda kell figyelni, hogy mit mire rebase-elünk (a bal oldali mezőbe kerül az, amit rebase-elünk (tehát itt mindig helyi ág van), és a jobb oldali mezőbe az, amire rebase-elünk (a remote ág).
    *
      Mivel a tortoise a parancssoros eszközök kimenetét elemzi, ha nem pont az a válasz, amire számít, sokszor azt írja, hogy a művelet sikertelen, pedig valójában rendben lezajlott.

SmartGit

A SmartGit egy gyorsan fejlődő eszköz, külön ablakban fut (nem az explorerből, mint a Tortoise), kipróbálóverzióban vagy nem kereskedelmi használatra ingyenesen letölthető.

    *
      A Rebase egyszerűbben érthető, mint TortoiseGittel
    *
      Összességében is kellemes felülete van
    *
      A Logban könnyen listázható az összes ág története, (hasonlóan a gitk —-all ablakhoz)
    *
      Pár dologban furcsa a szóhasználata, pl. “Revert” (nem a git-es értelemben használja, hanem svn-ből megismert módon)
    *
      Vigyázat: A nagy gombok közül a Push gomb automatikusan a legutolsó Fetch helyére akar push-olni, ami nálunk nem biztos, hogy a kívánt hely (a menüből kiválasztva felajánlja a választási lehetőséget)

JGit / Egit Eclipse vagy ZendStudio használatával

Alap Git-es funkciók elérhetők a Zend Studioban vagy Eclipse-ben is. Ehhez nyissuk meg a Help → Install New Software ablakot, és vegyünk fel a Work With mezőbe egy új szervert az Add… gombbal. A szerver címe: http://www.jgit.org/updates .

Válasszuk ki az Eclipse Git Plugin - Integration checkboxot, majd Next… . Régebbi ZendStudio-verzióknál előfordul, hogy nem tudja telepíteni a plugint.

Ezután a File → Import listájában megjelenik egy Git elem is, így lehet távoli Git repóból klónozni projektet. Ha már más módszerrel megcsináltuk a repositoryt, akkor csak akkor fogja észlelni, hogy valójában az Git-es, ha a projektre jobb gombbal kattintva kiválasztjuk a Team → Share elemet. Ekkor kiválaszthatjuk, hogy a projekt egy Git repó, és innen is tudunk commitolni, logot nézni, stb, és megjelennek az ikon- és fájlnévdekorációk is.
Alapfogalmak
Blob, fa, commit

A git szemben az SVN-nel, vagy CVS-sel egy elosztott verziókövető rendszer. Ez azt jelenti, hogy a projektben részt vevő minden fejlesztőnél megvan a teljes repository. Ez jól tud jönni akkor, ha gyakran szeretsz commitolni, de épp nincs hozzéférésed a (valamilyen értelemben vett) központi repositoryhoz (ez egy elég gusztustalan szó, hívjuk inkább tárolónak, vagy tárnak).

A tár mellett egy másik fontos fogalom a working copy, magyarul munkapéldány. Ezek azok a fájlok, amiken éppen dolgozol.

Fontos dolog, hogy git nem fájlokat, hanem tartalmakat tart nyilván. Az elosztottság mellett ez a legnehezebben felfogható koncepció. Ez azt jelenti, hogy a fájlok, amiket verziókövetünk, nem név szerint fognak a tárba kerülni. A fájlnevek tárolására valami egészen más dolog való.

A fájlok a tárba a SHA1 kulcsuk szerint kerülnek be. Ez azért (is) jó, mert ha több azonos tartalmú tartalmú fájlod van, akkor azok egy kulcs alatt, egy helyen lesznek tárolva. Az ilyen, nevüktől megfosztott, csupán SHA1 kulccsal tárolt fájlokat nevezzük blob-oknak.

A fájlok neveit az úgynevezett treek (fák) tárolják. Egy fa egy könyvtárnak felel meg. Nyilván van tartva, hogy benne milyen blobok és milyen más fák vannak. Itt szerepel a blob-ok fájlneve is.

A fenti két dolog (blob, fa) objektumok. A git ilyen objektumokkal dolgozik, ezekre alapszik az egész működése. Minden objektumra – így a fákra is – igaz, hogy az object store-ban, azaz az objektumtárban a SHA1 kulcsuk szerint tárolódnak. A fák SHA1 kulcsa a bennük lévő egyéb objektumok kulcsai alapján számolódik, így bármely tartalmazott objektum változása magával vonja a fa kulcsának változását is.

Fákból és blobokból tehát felépíthető egy egész fájlrendszer (pláne, hogy a fákban a fájlnév mellett más információk, pl. bizonyos attribútumok is tárolódnak). Itt viszont még szó sincs verziókról.

Ha módosítunk valamit a munkapéldányon, akkor a változásokat egy úgynevezett commit segítségével tudjuk a változásokat felvenni a tárba, sőt, egy üres tárba is csak commit segítségével tudjuk felvenni a legelső verziót.

A commit maga is egy git objektum. Egy commithoz mindig tartozik egy fa. Egy commithoz tartozó fa mondja meg azt, hogy milyen állapotban van a projekt az adott commit után.

Képzeljük el, hogy éppen módosítottunk valamit egy táron, amiben már van egy (kezdeti) commit. Valahogyan megmondjuk a gitnek, hogy változott a munkapéldány, és ezt legyen szíves felvenni a tárba. A git megvizsgálja a munkapéldányt, elkészíti a blobokat, és belőlük a fát, majd ezt hozzáad egy commitot is, ami a megváltozott munkapéldányunkhoz tartozó fára mutat. Ebben az esetben ehhez a commithoz hozzáíródik egy másik fontos információ is: mégpedig az, hogy melyik másik commitból származik.

Vegyük észere, hogy a különböző commitokhoz tartozó fákban sok lehet az olyan blob, ami éppen nem változott. A git ugye SHA1 alapján tárol, így a változatlan blobok csak egyszer tárolódnak. Ezért a különböző commitokhoz tartozó fáknak gyakran van sok közös blobja.

Minden commithoz tartozik tehát egy fa és (a legelső commit kivételével legalább) egy másik commit. A commitok SHA1 kulcsa is a fákéhoz hasonlóan képződik: a tartalmazott egyéb obejktumok kulcsai alapján.

Egy commit mutathat több másik commitra is. Ennek az értelme az, hogy így a merge-ök számon tarthatóak. Ha egy commit több másik commitra mutat, az azt jelenti, hogy több különböző commit eredményeképp létre jött változáshalmaz lett összefésülve, az ilyen összefésülést nevezzük merge-nek.
A SHA1 kulcs globális egyedi azonosító

A SHA1-es tárolási mód összefügg az elosztottsággal. Képzeljük el, hogy sok fejlesztő dolgozik ugyan azon a fájlhalmazon. Mindenki módosítgat, commitokat készít, ezeket néha valahogyan összemergelik. Egy idő után sok blob, fa és commit halmozódik fel, néha ezekről “beszélni kell”, nevükön kell nevezni őket. Erre a SHA1 kulcs tökéletesen alkalmas, mivel a SHA1-nek meg van az a jó tulajdonsága, hogy ugyan ahhoz a tartalomhoz ugyan azt az értéket rendeli. Egy másik tulajdonsága pedig az, hogy két eltérő tartalom esetén nagyon kicsi az esélye annak, hogy a SHA1 kulcsok megeggyezzenek. Ez az esély a gyakorlatban elhanyagolható (sokkal hamarabb fog a processzorod, vagy a memóriád hibázni, mint a SHA1 kulcs ütközni).

Ez a két tulajdonság biztosítja, hogy ha valaki azt mondja, hogy a “c6bc44748cd9a335d399dc9732bdfb34ee8a29e0”-s commit, akkor az a világon mindenhol azt a commitot fogja jelenti, amelyik a Dream CMS-be belerakta azt a változást, hogy a {form} smarty tagben lehessen a html attribútumot használni.

Ennek megfelelően a git parancsok esetében is a SHA1-es kulccsal nevezzük nevén a commitokat és az összes git-es objektumot is. Egy ilyen azonosító begépelése elég hosszú időt venne igénybe, ezért a gyakorlatban elég csak az első néhány karaktert megadni, ebből a git sokszor ki tudja találni, hogy melyik objektumra gondoltunk. Ehhez persze az kell, hogy semmilyen más objektum neve ne kezdődjön az adott karaktersorozattal. A fenti kommitot én jelenleg meg tudom nézni az alábbi paranccsal:

$ git show c6bc

A négy karakter viszont egy nagyobb projektnél sokszor ütközik, ezért inkább mondjunk öt-hat karaktert a telefonba, ennyit meg lehet jegyezni néhány másodpercig, és elég valószínű, hogy nem fog ütközni semmivel.

Levélben, vagy olyan helyen, ahol nincs lehetőség azonnali reagálásra, mindenképpen írjuk le az egész SHA1 kulcsot.
Ref, szimref, tag, branch, ilyenek

A ref (referencia szóból) egy mutató, amivel értelmes nevet adhatunk egy objektumnak, legtöbbször commitnak.

A refek legkézenfekvőbb használata a tagelés, így elnevezhetném a c6bc44748cd9a335d399dc9732bdfb34ee8a29e0-s commitot például “form_html_ok” néven, jelezve ezzel, hogy a fejlesztésnek ezen a pontján már lehet használni a {form} tagben a html attribútumot.

A refek tulajdonképpen fájlok, amit egy datab SHA1 kulcsot tartalmaznak, és a git táron belül (általában) egy direkt számukra fenntartott könyvtárban (refs) helyezkednek el.

A tageket a refs/tags könyvtárban szokás tárolni, így a fenti tag teljes neve a refs/tags/form_html_ok.

A tagek mellett használatos refek a branchek. A branch arra való, hogy megjelölje a fejlesztés különböző ágait. Minden git repositoryban van egy branch, amit masternek hívnak. A branchek között midig van egy “aktuális”, “amivel éppen dolgozunk”. A branchek a refs/heads könyvtárban helyezkednek el a táron belül.

A tagek “maguktól” nem módosulnak, ha egyszer beállítottuk őket, akkor úgy is maradnak. Az aktuális branch viszont mindannyiszor felülíródik, valahányszor commitot csinálunk, az új értéke pedig mindig a legutolsó commit lesz. A branch tehát “követi” a fejlesztés menetét.

A refeken kívül a git használ még úgynevezett symref, vagy szimref nevű dolgokat is. A szimref a POSIX-es symlink megfelelője, egyszerűen arra való, hgy másik ref-re mutassunk vele, a szimrefek így nem SHA1 kulcsokt, hanem egy ref nevét tartalmazzák.

A HEAD nevű szimref például arra való, hogy megjelölje az aktuális branchet, így a HEAD mindig az aktuális fejlesztési szál utolsó commitjára mutat. A HEAD egy azon kivételes (sym)refek közül, amelyek nem a refs könyvtár alatt találhatók. A HEAD symref a tár gyökérkönyvtárában van.
Használati esetek
Kezdés

A fenti elmélet után hozzáfoghatunk a munkához. Ha egy projektet nulláról kezdünk, az első dolgunk egy tár létrehozása. A tárak alapesetben ugyan abban a könyvtárban helyezkednek el, mint a projekt fájljai. A tár leggyakrabban a .git nevet kapja. Ettől el lehet térni, ezért a git man oldalak a .git könytár helyett $GIT_DIR-t emlegetnek.

Mielőtt hozzálátnánk, meg kell adni a nevünket és az e-mail címünket:

$ git config --global user.name "név"
$ git config --global user.email "e-mail cím"

Ennek megfelelően készítsük el a projekt könyvtárát, álljunk bele és hozzuk létre a tárat:

$ mkdir proba
$ cd proba
$ git init
Initialized empty Git repository in ... /proba/.git/
$

Fájlok hozzáadása és módosítása

Hozzunk létre egy fájlt egy sornyi tartalommal és adjuk hozzá a tárhoz

$ echo "Próba tartalom" > proba.txt
$ git add proba.txt

Ezzel a proba.txt fájl nem kerül bele a tárolóba. A git a változásokat először egy index nevű helyen gyűjti össze, az add parancs való arra, hogy a változásokat az indexbe felvegyük.

Az index tartalmát a következőképp adhatjuk a tárhoz:

$ git commit

A git kötelezővé teszi a commitokhoz leírások hozzáadását. Üres leírás megadásakor a commit nem fog végrehajtódni. A leírások első sora egy rövid leírás legyen, 50 karakter, vagy rövidebb. Ha ezen kívül van még valami hozzáfűznivalónk, azt egy sor kihagyása után, 72 karakteres, vagy rövidebb sorokba szedve tegyük meg.

A git alapértelmezett esetben a rendszerben beállított szerkesztőt használja, a Windows-os msysGit esetében ez a vi szövegszerkesztő.

A vi egy parancssori szövegszerkesztő. Ellentétben néhány kategóriabeli és a GUI-s editorokkal, ennek két alapállapota van: parancs mód és szerkesztő mód (utóbbi igazából sokféle állapotot takar). Az állapotok között billentyűkombinációkkal tudunk váltani. Mikor a vi elindul, alapból parancs módban van. Szerkesztő (pontosabban INSERT) módba az i betű lenyomásával kerülhetünk. Ilyenkor mozoghatunk a kurzorral a nyíl billentyűkkel, és a GUI-s szerkesztőknél megszokott módon szerkeszthetjük a szöveget. A git commit üzenet esetében ilyenkor lehetséges az üzenet beírása. Ha végeztünk mondanivalónk begépelésével, akkor parancs módba kell váltanunk, amit az <ESC> billenytyű megnyomásával tehetünk meg. Ha parancs módban gépelünk akkor a billentyűleütéseket a szövegszerkesztő értelmezni fogja. Ha szeretnénk menteni a szöveget, majd kilépni, használjuk a :wq (váltás parancsszerkesztő módba, write, quit) parancsot.

A szerkesztés befejezése után a következő üzenetet kapjuk:

1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 proba.txt

A tárban lévő commitokat a git log paranccsal tekinthetjük meg:

$ git log
commit 452837d8a0aa6f3ea0814792f90cd02d6ac5df34
Author: Tamas FABIAN <[email protected]>
Date:   Thu Dec 3 13:43:02 2009 +0100

    Próba commit

Csináljunk még egy commitot:

$ echo "Még egy sor" >> proba.txt
$ git add .
$ git commit

Most is kell a git add parancs, hogy a git észre vegye a módosításokat a munkapéldányban. Én most nem mondtam meg neki a konkrét fájlnevet, hanem a ., azaz az aktuális könyvtárat adtam meg neki. A git add parancs rekurzívan működik, ezért a git add kiadása az egész munkapéldányban megkeresi a változásokat.

A sikeres commit után érdemes kiadni a gitk parancsot, ami grafikusan ábrázolja a tár állapotát:

$ gitk

gitk parancs kimenete

A bel felső részen látjuk az egyes commitokat színes bogyókkal ábrázolva. A téglalap alakú címkék valamilyen refet jelölnek, taget, branchet, ilyesmit. A jobb oldalon az egyes commitokhoz tartozó üzenetek első sorát ovlashatjuk a kérpernyő alsó részén pedig a SHA1 kulcs, a módosított fájlok és az egyes módosított fájlokhoz tartozó diff-ek tekinthetők meg.

A gitk-s ábrák sok fejlesztő esetén egészen bonyolultak lehetnek. Íme egy részlet a CMS fejlesztésből:

gitk cms ábra

A gitk nagyon hasznos lehet akkor, ha egy vezető fejlesztő commitokat akar átszedni más projektekből, vagy az egyes fejlsztőktől.
Fájlok törlése, átnevezése

Fájlokat törölni és átnevezni rendre a git rm és git mv parancsokkal lehet. Valójában ezeket a parancsokat ritkán kell kiadni, a git ugyanis elég okos ahhoz, hogy észrevegye a törölt fájlokat és az átnevezéseket.

Vegyük észre, hogy az átnevezés tulajdonképpen azt jelenti, hogy ugyan az a tartalom a fában más fájlnév alá kerül. A tartalmak SHA1 kulcsa alapján az összehasonlítás nagyon könnyű.

A git add parancs nem veszi észre a törléseket. Ha szeretnénk, hogy a törléseket a git automatikusan felismerje, akkor használjuk az alábbi kombinációt:

$ git add .
$ git commit -a

A git add észreveszi az új fájlokat és a módosításokat is, viszont a törléseket nem. A git commit -a észreveszi a módosításokat és a törléseket, de az új fájlokat nem. A kettő kombinációjával biztos a siker. ;)
Fájlok figyelmen kívül hagyása

Ha szeretnénk, hogy néhány fájlt a git ne verziókövessen, akkor hozzunk létre egy .gitignore fájlt, és írjuk be a figyelmen kívül hagyandó fájlneveket.

Gyakori példa erre, hogy szerretnénk egy üres könyvtárat verziókövetni. A könyvtár nyilván azért kell, mert majd lesz benne valami, de semmi olyan nem lesz, amit verziókövetnénk. A látszólagos probléma az, hogy gittel nem lehet üres könyvtárakat verziókövetni. A probléma megoldható, ha velerakunk valamilyen fájlt. Mivel a könyvtárban olyan fájlok lesznek, amit nem verziókövetünk, ezért rögtön egy .gitignore fált is tehetnénk bele. És tényleg, a “best practice” ebben az esetben az, hogy hozzunk létre a követendő könyvtárban egy .gitignore fájlt az alábbi tartalommal:

    *

!.gitignore

A gitignore fájlban ugyanis mintákat adhatunk meg. A * ugye bármilyen fájlt jelent az kérdéses könyvtárban. Ha egy minta elé ! kerül, akkor a minta “kivonódik” az előző sorokban megadott mintákból, így a fenti két sor azt jelent: “minden fájl, kivéve a .gitignore”. A könytárban így minden fájl figyelmen kívül lesz hagyva, kivéve magáta a .gitignore-t.
Fájl változási naplója

Ha kíváncsiak vagyunk arra, hogy egy fájl bizonyos sorát ki módosította, használjuk a git blame parancsot:

$ git blame proba.txt
^452837d (Tamas FABIAN 2009-12-03 13:43:02 +0100 1) Próba tartalom
d2ef5103 (Tamas FABIAN 2009-12-03 14:06:01 +0100 2) Még egy sor

A parancs kiírja a kérdéses fájlt, minden sor elé odabiggyeszti annak a commitnak a szerzőjét, amelyik a legutóbb módosította az adott sort.

A ^ jel a SHA1 töredék előtt azt jelenti, hogy a commit az épp aktuális HEAD (ami ugye egy szimref, ebben az esetben konkrétan a refs/heads/master-re mutat, tehát ez a legutolsó commit a branchben).
Tagelés

Taget egyszerűen a git tag paranccsal hozhatunk létre:

$ git tag v0.1

A fenti művelet a HEAD által mutatott commitra helyez el egy taget, aminek a neve “v0.1” lesz. A parancsnak további paraméterként megadható egy commit is, hogy hová kerüljön a tag. Én az első commitra is teszek egyet, aminek a SHA1 kulcsát a git log parancssal nézek meg:

$ git log
commit d2ef51033ad808379640186d145025868f9201fb
Author: Tamas FABIAN <[email protected]>
Date:   Thu Dec 3 14:06:01 2009 +0100

    Még egy sor

commit 452837d8a0aa6f3ea0814792f90cd02d6ac5df34
Author: Tamas FABIAN <[email protected]>
Date:   Thu Dec 3 13:43:02 2009 +0100

    Próba commit
$ git tag kezdetek 4528
$

A parancsnak ugye elég megadni az első néhány karaktert is a SHA1 kulcsból. Ebben az esetben már az első karakter is egyértelműen azonosította volna a commitot.

A létrehozott tageket kevésbé látványosan így tekinthetjük meg:

$ git tag
kezdetek
v0.1

Látványosabban pedig a gitk-val:

Branchek

Fejlesztői ágakat létrehozni a git branch paranccsal tudunk. Hozzunk létre egy új ágat:

$ git branch experimental

A branch ezzel létre is jött. Megtekinthetjük a git branch parancsot paraméter nélkül használva:

$ git branch
  experimental
* master

A csillag a master mellett azt jelenti, hogy az az aktuális branch. Branchet váltani a git checkout paranccsal lehet:

$ git checkout experimental
Switched to branch 'experimental'
$ git branch
* experimental
master
$

Most módosítsunk valamit az experimental branchben:

$ echo "Új fájl" > new.txt
$ git add .
$ git commit -a

Az add / commit -a kombót csak a megszokás kedvéért adtam ki így, most épp nem lenne rá szükség.

Ha most átváltunk a master branchre, az új fájl eltűnik.

$ git checkout master
Switched to branch 'master'
$ ls -la
összesen 16
drwxr-xr-x  3 netom netom 4096 2009-12-03 15:34 .
drwxr-xr-x 74 netom netom 4096 2009-12-03 15:32 ..
drwxr-xr-x  8 netom netom 4096 2009-12-03 15:34 .git
-rw-r--r--  1 netom netom   29 2009-12-03 14:05 proba.txt

A gitk –all parancs kiadásával látható, hogy az experimental branch eggyel a master előt jár. A –all kapcsoló azt mondja, hogy ne csak a jelenlegi, hanem minden branch commitjait szeretnénk látni:

Az experimental branch változásait áthozhatjuk a masterbe a git merge paranccsal. Jelen esetben a merge csupán egy “fast forward” (előre tekerés) lenne, mert a masterben semmi olyan commit nincs, ami az experimentalban ne lenne benne, így az experimental branch commitjai egy-az-egyben áthozhatóak. Tulajdonképpen ilyenkor az történik, hogy a refs/heads/master ref felveszi a refs/heads/experimental értékét.

Vizsgáljunk meg ennél egy bonyolultabb esetet: módosítsunk a masteren:

$ echo "Szöveg" > proba2.txt
$ git add .
$ git commit -a

A gitk-ben most ez fog látszani:

Látszik, hogy a master és experimental branchek által mutatott commitnak is a v0.1 taggel jelölt commit a kiinduló pontja. Ott ágazott el a fejlesztés. Ha most szeretnénk az experimental branch változásait áthozni, akkor arra az egyi lehetőség a merge.
Merge

Adjuk ki a git merge parancsot:

$git merge experimental
Merge made by recursive.
 new.txt |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 new.txt

A merge automatikusan egy commitot is jelent. Az ilyen commitoknak több “kiindulás commitjuk” lesz, és merge commitoknak nevezzük őket. Gitk-ban a jelenlegi helyzet így fest:

Sok párhuzamos fejlesztés esetén a fejlesztési történet nagyon csúnya “metrótérképpé” fajuhat. Ha szeretnénk a fejlesztési történetet lineárisan tartani, akkor a merge helyett egy másik funkcióval, a rebase-szel kell dolgoznunk.
Rebase

A rebase arra való, hogy az aktuális branchben ejtett változásokat egy másik branch tetejére pakolja. Az előző esethez hasonlóan módosítok a master és az experimental branchben is egy-egy dolgot:

$ echo "Próba" > proba3.txt
$ git add proba3.txt
$ git commit -m "Harmadik próba fájl"
[master 02c4d3d] Harmadik próba fájl
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 proba3.txt
$ git checkout experimental
Switched to branch 'experimental'
$ echo "Még egy új fájl" > new2.txt
$ git add new2.txt
$ git commit -m "Még egy új fájl"
[experimental 8b2514e] Még egy új fájl
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 new2.txt

A gitk –all parancs most erre ezt mondja:

Látszik, hogy a master és az experimental elágazott az “Új fájl” megjegyzéssel illetett commitnál. A masterben ehhez képest két új van (a merge és amit most csináltunk), az experimentalban pedig csak a legutóbb létrehozott.

A feladat az, hogy az experimental branchet rakjuk rá a master tetejére:

$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: Még egy új fájl

Ezután a tárunk így néz ki:

Látható, hogy az experimental most már a master tetejéről ágazik le, így az az állapot állt elő, mintha most ágaztunk volna le, és csináltunk volna egy darab commitot.

Ha kiderül, hogy az experimental branchben a fejlesztett funkció hasznos dolog, akkor átkerülhet a masterbe egy egyszerű előretekeréssel:

$ git checkout master
Switched to branch 'master'
$ git merge experimental
Updating 02c4d3d..d99e58a
Fast forward
 new2.txt |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 new2.txt

Nézzük meg most a tárat:

Fast forward esetén nincs szükség külön merge commitra, az experimentalon lévő commitot egy-az-egyben át lehet hozni a masterre, tehát tulajdonképpen csak a master címkét kell eggyel feljebb tenni.
Klónozás

A git ugye elosztott verziókövető rendszer, alapfilozófiája, hogy minden fejlesztőnél legyen ott egy teljes tároló. Tárolókat egyszerűen le is lehet másolni mindenestül, mégis jobb, ha a következőt csináljuk (ugye még mindig a proba könyvtárban állva):

$ cd ..
$ git clone proba proba2
  Initialized empty Git repository in /home/netom/proba2/.git/
$ cd proba2

Ezzel létre is hoztunk a proba2 könyvtárba a proba tár másolatát. Ez abban különbözik a proba tártól, hogy minden branchére van benne rá egy hivatkozás. Ez a hivatkozás is egy branch, ami arra való, hogy nyomon követhessük a klónozott, vagy más tárak állapotát. Az ilyen branchet tracking branchnek, vagy követőágnak nevezzük.

A követőágak nem látszanak a git branch parancs kimenetében. A követőágakat a git branch -a paranccsal nézhetjük meg:

$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/experimental
  remotes/origin/master

A követőágak a remotes könyvtárba, ezen belül is távoli táranként külön könyvtárba kerülnek. A regisztrált távoli tárakat, más névet remoteokat a git remote paranccsak tudjuk megtekinteni:

$ git remote
origin
$

Láthatjuk, hogy van egy távoli tárunk, aminek origin a neve.

A klónozott tárakra az eredeti tárakban nincs hivatkozás, ezért a klónok nem kapnak értesítést arról, hogy ha a valamelyik távoli tárban történik valami. A változásokat a git fetch paranccsal hozhatjuk át. A git fetch megnézi, hogy változott-e a távoli tár, és a szükséges objektumokat (commitok, fák, blobok) áthozza. Egy fetch hasonló egy előretekeréshez (tulajdonképpen az is).

Attól, hogy a távoli tárakat fetch-eljük, a változások még nem kerülnek át a munkapéldányba, sem a lokális (“sima”) ágakba. A változások áthozásához ugyanúgy mergeöt, vagy rebaset kell csinálni, mintha lokális ágakban történtek volna a módosítások.

Fontos, hogy követőágba soha ne commitoljunk lokálisan, hiszen ezeknek pont az a lényege, hogy pontosan megeggyezzenek a távoli tárak ágaival.

Távoli tárat létre is tudunk hozni az origin-en kívül a git remote add <név> <url> paranccsal. Ha sok távoli tárunk van, akkor mindet egyszerre tudjuk frissíteni a git remote update paranccsal.

Változtassunk meg egy fájlt a klónozott tárban, és commitoljunk:

$ echo "...és még egy sor" >> proba.txt
$ git add proba.txt
$ git commit

Ezt a változtatást a távoli tárba a következőképp vihetjük át:

$ git push
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 317 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
To /home/netom/proba
   d99e58a..e3cdbdd  master -> origin/master

A távoli tárakat és a fetch/merge/rebase/push parancsokat nagyon sokféleképpen lehet használni. A konkrét munkafolyamatokat az adott cégre/projektre kell szabni.