Na úvod nebude špatné ujasnit si, proč vlastně používat nějaký nástroj na správu změn, a nebo, chcete-li, na správu obsahu (SCM – source code management). Obsahem je v tomto případě většinou myšlen zdrojový kód, prostý text apod.
Asi téměř každý, kdo se vydal na nejistou cestu úpravy nějakého textu, měl chuť mít v záloze pro případ neúspěchu předešlou verzi. Někteří z nás mají i tak neuspořádaný život a projekty, že musejí pracovat na několik různých variantách téhož projektu najednou. A největší masochisté pak zapojují do této činnosti i další nadšence. Výsledkem může být košatě se větvící projekt o mnoha lidech.
Prvně asi každý, kdo je postaven před podobný problém, sáhne po velmi snadném a obvyklém řešení v podobě příkazu cp foo foo.old". Ty tvořivější a tvrdohlavější pak ještě po mv foo.old foo.old2; cp foo foo.old. To je často metoda hodná admina ničícího vlastní /etc, ale nehodí se na dlouhodobější práci.
Časté a podstatně sofistikovanější řešení je nainstalovat CVS. Tedy ono to není zase tak moc přímočaré. Je nutné mít nejen klienta, ale i server. Nějak řešit práva, bezpečnost apod. Důsledkem je, že CVS nacházíme jen tam kde to úsilí za to stojí. Bohužel CVS je opravdu zastaralé a většinou vede lidi a celé projekty k tomu, že přizpůsobují styl své práce a celé své uvažování o projektu tomuto nástroji. (Věřím, že ti co i dnes ráno pazourkem rozdělávali oheň ve své IT jeskyni se s námi o své „nesahejte nám na CVS“ podělí v debatě pod článkem.
Lze to i jinak. Lze nalézt novější nástroje které stejně dobře poslouží na správu několika konfiguračních souborů jako i na udržení projektu o mnoha stovkách souborů a stovkách přispěvatelů s tokem i několika stovek změn za měsíc.
V našem případě budeme mluvit o GITu. Předpokládejme, že čtenář nějaké zkušenosti s nějakým SCM již má.
Motivací pro vznik GITu bylo prázdné místo po z licenčních důvodů dále již nepoužitelném BitKeepru. V té době se pro linuxový kernel nehodil žádný existující nástroj. Inspirací pro GIT byl jiný SCM, a to Monotone. Důkazem toho, že se GIT opravdu povedl, je neustále se zvětšující počet projektů, které ho používají. A už dávno nejde jen o projekty okolo linuxového kernelu.
Asi nejpodstatnější pro pochopení GITu je celkový pohled, jakým se GIT kouká na projekt a jeho správu.
Obecně můžeme svět SCM rozdělit na centralizovaný a distribuovaný. Srdcem centralizovaného modelu je server na kterém se uchovávají veškeré změny. Server je sdílen vývojáři, a ti ho aktivně používají pro svou práci. Na první pohled to vše vypadá jednoduše a snadno použitelně. Ale…
Vše je centrální. Nelze být pro práci s takovým SCM offline. Generování diffů, procházení historie je pomalé. (Ve světě CVS existuje pro tento a pár dalších problémů workaround jménem Subversion.)
Je nutné rozdat vývojářům práva zápisu do centrálního repositáře a zajistit bezpečnost. Práva znamenají nutnost definovat, kdo je a kdo není dostatečně zodpovědný a prověřený. To vede k vytvoření určitých politik okolo projektu.
Protože repositář je sdílený a práce jednoho vývojáře ovlivňuje ostatní, je nutné definovat pravidla, co je a co není vhodné pro „oficiální“ commit.
U větších projektů jsou pak politiky a pravidla zdrojem třenic mezi vývojáři.
Výsledkem je, že nástroje používající centralizovaný model jsou degradovány do pozice pouhého archivačního nástroje, který uchovává, kdo co udělal (a v případe CVS ani to pořádně). Podobný nástroj pak není nástrojem vývojářským. V případě CVS pak vývojář volá příkaz commit až na dokončený a relativně stabilní patch (aby mu nikdo nenadával). Centralizovaný SCM tak minimálně pomáhá s vlastním vývojem a prací na kódu.
Dalším problémem je, že patch může být opravdu rozsáhlý a práce na něm trvat i mnoho dní. Během této doby se kód v centrálním repositáři může změnit a je tedy nutné před finálním umístěním změny do repositáře řešit konflikty. Práce s velkým souborem změn je pak pro zlost.
Řešením je používat nějaký privátní branch a rozdělovat práci na menší části, a do oficiálního repositáře pak umístit až vše najednou. Nepříjemností u centralizovaného modelu je, že i každý váš branch bude na centrálním serveru. Může tak trpět vaše chuť na soukromí a hlavně takový branch se podobně jako celý centralizovaný repositář obtížně používá. (V porovnání se schopnostmi GITu je větvení projektu v CVS téměř nepoužitelné.) Další komplikací je nutnost mít právo zápisu v centrálním repositáři. Výsledkem je, že minimum lidí vůbec tuší k čemu je branch a raději nic takového nepoužívá.
Ve světě open source je celkem běžné, že na kódu příležitostně pracují i lidé kteří nemají zájem věnovat se projektu dlouhodobě, ale jen si chtějí něco ověřit, přidat nějakou vlastnost, opravit nějakou chybu. Centralizovaný SCM je pro ně jen způsob, jak se dostat k aktuálnímu kódu. Nic víc. Nemají právo zápisu v centrálním repositáři a nemohou udělat commit, branch apod. Většinou jsou nuceni vystačit s diff -u old new.
Distribuovaný model je daleko otevřenější. Nedělá rozdíl mezi vývojáři. Každý má možnost používat naplno všechny vlastnosti daného SCM.
V případě GITu má každý uživatel plnou kopii repositáře daného projektu a může s ní dělat, co se mu zlíbí. Váš lokální repositář může obsahovat i kopie libovolného počtu jiných repositářů v podobě samostatných branchů. Tedy nemusíte následovat jen základní linii daného projektu, ale i různé dočasné větve apod.
Nejzajímavější je pak tok změn (patchů). Ač je to technicky možné, je u GITu neobvyklé sdílet repositáře a rozdávat právo zápisu. Naopak každý má plnou kontrolu nad svým repositářem. Maintainer si sám rozhoduje, v jakém pořadí bude aplikovat změny a čemu se bude věnovat.
Patche se předávají e-mailem nebo se read-only zpřístupní repositář, kde je daná změna uložená a kdo má zájem, si ji stáhne do svého repositáře. V praxi pak projekt má nějaký oficiální repositář, který je read-only (zápis má jen maintainer) a obsahuje to, co se připravuje pro oficiální release. Takový veřejně dostupný repositář si pochopitelně může udělat každý. Podobě lze vytvářet i mirrory apod. Tyto veřejné repositáře se většinou nepoužívají k vlastní práci. Na práci má každý svou repositáře na svém stroji.
Mezi jednotlivými repositáře lze předávat změny pomocí příkazu pull a push. Je, ale běžné, že k maintainerům se posílají patche pomocí e-mailu prostřednictvím nějakého mailing-listu. Vede to k tomu, že patch je prohlédnut vice lidmi a je možné nad ním debatovat. Pro práci s e-mailem má GIT solidní podporu (extrahováni patche z mailu a posláni patche).
V následujícím článku se seznámíme s repositáři.
ČLÁNKY DO MAILU