Revision as of 09:23, 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.

Repository létrehozás

Centrális másolat

Lokális másolatok