Revision as of 10:07, 30 September 2016

Áttekintés

A git egyrészről szeretne teljesen elosztott lenne, de valójában ugyan úgy van egy "mester kópia" a szerveren ahogy az SVN-ben, amit mindenki lemásol magához és oda tölti vissza a változásokat.

Főbb tulajdonságok

• Minden felhasználónál a teljes repository megtalálható. Ez azt jelenti, hogy mikor készítünk magunknál egy "másolatot" (szándékosan használtam itt a másolat szót), akkor valójában az egész repository-t lemásoljuk magunkhoz az összes branch-el, tag-el, változtatással együtt. Tehát anélkül hogy hozzá kéne férni a szerverhez, a lemásolás időpontjáig az összes létező lekérdezés lefuttatható mert minden adatunk megvan hozzá. Nyilván ha valaki már felvitte a változtatásit a szerverre, akkor előbb nekünk frissíteni kell a helyi adatbázisunkat, tehát ez szintén csak egy látszat előny, egy átlagos méretű projektben ennek szerintem semmi haszna. Másrészről ha nagyon nagy a projekt, akkor a lokális tárhely szükséglet is gondokat okozhat. Azt mondják, hogy ez az (ál)decentralizáltság azért is jó, mert több helyen megvan pont ugyan az. Ez azért kicsit ferdítés, mert egy valódi szerveren az adatbiztonság mindig meg van oldva, az adatvesztés nem fordulhat elő. Nem is beszélve arról, hogy akárcsak az SVN-nél, a lokális kópiák általában nem a legfrissebbek, a teljes kép mindig csak a szerver kópián van meg.

• Az egyes felhasználóknál lévő lokális kópiák teljes értékű verzió követő rendszerek. Ugyan úgy "commit"-álni kell a lokális kópiánkba, mint az SVN-nél a távoli szerverre. Ez pl nagyon hasznos lehet valakinek, aki csak egy lokális verzió követőt akar felrakni magához gyakorlatilag egy parancs kiadásával. Ha akarjuk, innen lehet feltolni egy másik repozitory-ba, tipikusan a szerverre.

• A branchek közötti váltás csak egy mozdulat: Mivel nálunk a teljes kópia (legalább is annak valamilyen időpillanatban létező változata) ezért egy paranccsal át lehet állni egy adott ágra. Nagy különbség még, hogy egyszerre csak egy ág aktív, amin éppen dolgozunk. Az ágak közötti lokális merge nagyon egyszerű. Ide - oda "beleolvaszthatjuk" a forráskódunkat egyik ágból a másikba, majd bármelyik ágat feltolhatjuk a szerver repository-ba. Ez elég hasznos lehet.

• A repository-k hierarchiába szervezhetőek. Valójában erre lett kitalálva a git. Ez lehetővé teszi akár több ezer együtt dolgozását ugyan azon a giga projekten. Szerintem itt jön elő a git igazi előnye, több ezer ember nehezen használna egyszerre SVN alapú projekteket. Egy giga projektben több fő fejlesztői csoportot kell kialakítani a fő feladatok mentén. Majd azokat további kisebb csoportokra lehet osztani. Git-ben csinálunk egy legfelső repot, ez lesz a legfelső szintű "mester" repo, ezt lemásolják második szintű "mester" repók. Ezt használják a fő fejlesztői csoportok. Nevezzük ezt "második szintű másolatoknak." Ezen repoknak csak olvasási joga van a mester példányhoz. A második szintű másolatokat lemásolják a harmadik szinten lévő fejlesztői csoportok. Ezen harmadik szintű csoportok is csak olvasni tudják a második szintet. A harmadik szintű másolatokhoz már közvetlen fejlesztők kapcsolódnak, oda tolják fel a fejlesztésüket. Az első körös tesztelést önállóan végzik a 3. szinten lévő csoportok. Mikor kész vannak elküldik email-ben a változtatást a 2. szinten lévő szülőjüknek. A második szinten lévő felelősök összegyűjtik a 3. szintről érkezett fejlesztéseket, és belerakják helyben a 2. szintű másolatokba. Ezek után 2. szinten is tesztelésre kerül a fejlesztés. Majd a fejlesztések végül elküldésre kerülnek a mester repóba.

Felépítés

A lokális git másolatunk három részre osztható.

• Lokális, verzió kontrollált másolata a fájloknak. Itt az összes ág és verzió megtalálható a lokális másolat utolsó frissítése óta. (A centrális repó-ban közben már lehet hogy tök más van)
• staging are: ez egy átmeneti tároló. Itt kell összegyűjteni azokat a fájlokat, amiket commit-álni szeretnénk a lokális repónkban. (általában felesleges)
• working copy: ez a jelenlegi munkaterület. Itt a lokális másolat valamelyik ága van berakva (brach). + itt vannak a még nem verziózott fájlok. Ez az ami megjelenik a fájlrendszerben, ha megnyitom a git mappáját a projektnek. Azt hiszem a git szimbolikus linkekkel dolgozik. Ezért tudja olyan gyorsan kicserélni a munkaterületet egy másik branch-re. Ha átállunk egy másik ág-ra, akkor a fájlrendszerben már a másik ág fájljai fognak látszani. Így az svn-nél megszokott mappa / branch szemlélet itt nem célravezető.

Ha van egy üres lokális git repository-nk, akkor az új fájlokat elsőként az add paranccsal hozzá kell adni a staging területhez. Innen a commit paranccsal adhatjuk hozzá az éppen használt ág-hoz. Alapesetben ez a master, vagyis a fő ág. (trunk az SVN-ben).

A megfelelő branch (ág) lokális változatát a push paranccsal tolhatjuk fel a "központi" repository-ba (ugyan abba az ágba). (Akár hogy is nézzük, igazából ez nem egy decentralizált verzió követő rendszer). A központi másolatból a pull paranccsal másolhatjuk át a kiválasztott ágat a mi lokális másolatunk megfelelő ugyan azon ágába.

Note
Fontos különbség még az SVN-hez képest, hogy ha valaki kiad egy push parancsot, és feltolja a lokális változtatásait a lokális repóba, akkor a git úgy veszi hogy az egész branch módosult

. Ha valaki egy másik felhasználó push parancsa után egy tök másik fájlt akar feltolni ugyan abba a branch-be, akkor csak akkor fogja megtenni, ha az új változtatásokat elsőként leszedi a pull paranccsal, lokálisan egyesíti a fájlokat, majd utána az egészet feltolja.

Támogatott protokollok

A felhasználók (kliensek) a központi példányt ssh, http vagy git protokollon keresztül érhetik el. A változásokat a push paranccsal tolhatják fel a központi példányba, és a pull paranccsal hozhatják le.

Mi az ssh protokollt fogjuk használni, mivel ha van ssh hozzáférés egy szerverhez, akkor azonnal használható minden további komponens nélkül. Tehát ssh esetén nem kell külön egy git damon fusson a szerveren mint az SVN esetében. A centrális példány is csak fájlok összessége, amihez ssh-val hozzáfér a lokális git kliens.

Note
Azt kell látni, hogy az svn-el ellentétben az esetek többségében nem fut egy git daemon a szerver gépen

A lokális git programunk az adott (fájl megosztást is támogató) protokollon keresztül eléri a szerveren lévő fájlokat. Tehát nincs más dolgunk, mint a klienseknek egy olyan URL-t biztosítani, ami az adott központi git repository mappájára mutat. A többit elintézi a git.

• HTTP: az apache-ban készíteni kell hozzá egy virtuális hosztot, kb negyed óra működésre bírni. Az autentikációt az apache végzi, előnye, hogy anonymous hozzáférést nagyon egyszerű vele biztosítani.
• SSH: ehhez semmit nem kell konfigurálni. Ha egy felhasználó ssh-n keresztül képes belépni, és hozzáférni a git központi repository fájljaihoz, akkor azonnal használni tudja azt, nincs szükség egyéb konfigurációra. Pont ezért ez a legelterjedtebb protokoll.
• GIT: ez a git saját protokollja, kifejezetten anonymous hozzáférésre készült az open source világ számára.

Repository létrehozás

Nem feltétlen kell központi git repository, azt is megtehetjük, hogy csak egy lokális repository-t inicializálni, de akkor nem tudunk együtt dolgozni másokkal. Ezért mi elsőként egy központi repository-t fogunk készíteni a szerveren, majd a clone paranccsal ezt fogjuk lemásolni a munkaállomásokra mint lokális másolatok.

Centrális másolat

Álljunk bele abba a mappába ahol a központi másolatot ki szeretnénk alakítani a szerveren, majd a git init paranccsal inicializálhatjuk a centrális repository-t. Itt megint megemlíteném, hogy két speciális kapcsolót kell használni az init parancs mögött, amivel jelezzük, hogy ez lesz a központi (mester) példány.

• --bare: Ennek a hatására a szerveren egy speciális repository fog létrejönni, ahol nem lesz staging vagy working area, a fájlok binárisan lesznek tárolva, ember számára nem lesz olvasható a tartalom. Ez kifejezetetten szerver üzemmódra van, itt nem lehet használni a commit vag az add parancsokat.
• --share: Szintén az jelzi, hogy ez a szerver példány, amihez többen fognak hozzáférni, így a git a push paranccsal megkapott fájlok tulajdonosát speciálisan fogja beállítani, hogy a csoportból mindenki hozzáférjen.

Tehát, inicializáljuk

$ cd /home/adam/git/testRepo
$ git init --bare --shared

Ekkor létrejött a szerver git struktúra:

$ ll /home/adam/git/testRepo
total 32
drwxrwsr-x.  2 adam adam 4096 Sep 29 16:57 branches
-rw-rw-r--.  1 adam adam  126 Sep 29 16:57 config
-rw-rw-r--.  1 adam adam   73 Sep 29 16:57 description
-rw-rw-r--.  1 adam adam   23 Sep 29 16:57 HEAD
drwxrwsr-x.  2 adam adam 4096 Sep 29 16:57 hooks
drwxrwsr-x.  2 adam adam 4096 Sep 29 16:57 info
drwxrwsr-x. 13 adam adam 4096 Sep 29 17:59 objects
drwxrwsr-x.  4 adam adam 4096 Sep 29 16:57 refs

SSH-val az alábbi URL-n tudják a kliensek lemásolni a központi másolatot:

git clone ssh://<user>@<host>/<full path to git repository directory>

A mi esetünkben:

git clone ssh://adam@jenkins.alerant.hu/home/adam/git/testRepo/

Lokális másolatok

Központi példány másolása

Álljunk bele a lokális gépen abba a mappába, ahol a git repository-k vannak, de ne hozzunk létre a most másolandó repónak egy saját mappát, a copy parancs ezt majd megteszi.

Adjuk ki a git clone parancsot. Ha nem kulcsos az azonosítás az ssh szerveren, akkor be kell írjuk a jelszavunkat minden egyes hozzáféréskor.

$ cd /home/adam/git
$ git clone ssh://adam@jenkins.alerant.hu/home/adam/git/testRepo/
Cloning into 'testRepo'...
adam@jenkins.alerant.hu's password: 
remote: Counting objects: 9, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 9 (delta 1), reused 0 (delta 0)
Receiving objects: 100% (9/9), done.
Resolving deltas: 100% (1/1), done.
Checking connectivity... done.

Ezzel a /home/adam/git mappában létrejött a repository nevével megegyező testRepo mappa. Láthatjuk, hogy a szerver struktúrával ellentétben, most létrejött a .git mappa. Ha nem szerver módban hozzuk létre a repository-t, akkor létrejön a working area is, ami egy fajta virtuális fájlrendszer.

Git beállítások

Végezzük el az alap git beállításokat. A git a felhasználó home mappájában a .gitconfig fájlban tárolja a beállításokat. Ezt vagy kézzel írjuk közvetlenül, vagy a git config --global paranccsal.

$ git config --global user.name "Berki Adam"
$ git config --global user.email berki.adam@alerant.hu
$ git config --global core.editor mcedit

Ekkor a ~/.gitconfig fájlban az alábbi sorok jöttek létre:

[user]
	name = "Berki Ádám"
	email = berki.adam@alerant.hu
[core]
	editor = mcedit

Git használata