Git

SFD (http://szszk.sed.hu/2007), Szeged

Transcript

1. 1 A GIT verziókezelő rendszer Vajna Miklós <vmiklos@frugalware.org>
2. 2 Áttekintés • Az elosztott verziókezelő rendszerekről (SCM) • A GIT rövid története • A GIT legszembetűnőbb előnyei • A GIT által támogatott fejlesztési modellek • A GIT hibakeresési támogatása • A Frugalware a GIT verziókezelőre vált • Ajánlott irodalom
3. 3 Az elosztott SCM-ekről CVS is not the answer, CVS is the question. No is the answer. -- Theodore Ts'o
4. 4 Az elosztott SCM-ekről • A repó másolásához elég az olvasási jog • Több szabadság a fejlesztőnek: – Offline commitok – „Commit early, commit often” • Implicit biztonsági mentés mindenki által (nincs „single point of failure”) • Szimmetrikus: nincs különbség a repók között • Mindenkinek van írási joga a saját repójába
5. 5 A GIT rövid története • 2002: BitKeeper a Linux fejlesztéséhez • 2005 április 6: A BitKeeper eltörli az ingyenes licencet, Linus a GIT megírásába kezd • 2005 április 18: Az első merge • 2005 június 16: A hivatalos kernelfejlesztéshez használatos SCM a GIT. • 2007 február: GIT 1.5.0 – igazi SCM
6. 6 A GIT rövid története And then realize that nothing is perfect. Git is just closer to perfect than any other SCM out there. -- Linus Torvalds
7. 7 A GIT legszembetűnőbb előnyei • Az elosztott SCM-ek szokásos előnyei • Gyors. Felismerték, hogy a sebesség nem másodlagos! Bármilyen gyakran használt műveletet ha lassúnak érzünk, akkor bátran lehet reklamálni :) • „Do one thing and do it well.” - könnyen szkriptelhető • A projekt korábbi történetét lehetetlen észrevétlenül megváltoztatni. • GIT-SVN
8. 8 A GIT legszembetűnőbb előnyei • Sok kis kényelmes szolgáltatás, ami miatt önmagában nem lenne érdemes váltani: – detached HEAD – shallow clone – rebase – stash – submodules
9. 9 A GIT hátrányai • Eredetileg csak tartalomkezelő, nem SCM. • A doksi szépen fejlődik de még mindig nagyon nehéz elindulni (kb. egy hét szenvedés). • Windows támogatás még csak most éledezik. • Nagyon nagy tudású, az elején nehéz eligazodni, hogy „mi kell nekem és mi nem”. • Lista vége: kevés hátrány :)
10. 10 Támogatott fejlesztési modellek • CVS-szerű – továbbra is lehet egy központi repót használni, amennyiben az adott feladat azt kívánja (pl. fordításoknál) • Linus mód – mindenkinek van egy publikus repója, amiből bárki bármit átemelhet – sok fejlesztő esetén ez a modell jól skálázódik
11. 11 A GIT hibakeresési támogatása • git bisect – hiba keresése bináris kereséssel – interaktív: igen/nemmel válaszolunk, hogy a hiba jelentkezik-e – automatikus: egy adott parancs kimenetét nézi • pl. memóriahibák keresésénél hihetetlen hatékony • sokan kizárólag ezért képesek voltak belevágni a GIT használatába :)
12. 12 A Frugalware és a GIT • Korábban a Darcs verziókezelőt használtuk • Szép és jó volt, de „kinőttük”: nagy projektek esetén katasztrófálisan skálázódik (nálunk ezt 25000 patch környékén értük el) • Mikor alternatívát kerestünk, két szempont volt: – támogasson mindent, amit használtunk a Darcsból – legyen gyors
13. 13 Az esettanulmány folytatódik • Mi az, ami nem változott (se jobb, se rosszabb): – elosztott működés – első get/clone időigényes • Mi az. amit nyertünk: – még a legkritikusabb fejlesztők is meglepődtek a sebességen – egy tucat kényelmes funkció, ami nélkül ugyan lehet élni, de hatékonyabbá teszik a munkát • Átállás előkészítése kb. 1 hónap volt (sok idő!)
14. 14 Ajánlott irodalom • Referencia: man oldalak (jól dokumentált) • Every day with GIT: egy kedvcsináló, amely végre kihagyja az első körben érdektelen részleteket • User Manual: nem igazán hangsúlyozott, pedig ennek elolvasásával napokat spórolhatunk meg magunknak :)
15. 15 Elérhetőség • Honlap: http://git.or.cz • Levelezési lista: git@vger.kernel.org – nagy forgalmú, a kezdőknek türelmesen segítenek, a tapasztaltabbaktól sokat lehet tanulni • IRC csatorna: #git @ irc.freenode.net – segítőkészek, kezdeti triviális kérdésekben nagy segítség, de koránt sem biztos, hogy minden kérdésünkre választ kapunk