Hlavní navigace

GIT: distribuovaná správa revizí

Karel Žák

Každý, kdo spravuje velké množství obsahu, časem přijde na to, že by potřeboval software, který by mu pomohl nad tímto obsahem držet ochrannou ruku. Velmi často mezi uživatele takových aplikací patří vývojáři, ale hodí se také (ne)pořádným administrátorům. Představíme si velmi silný nástroj GIT.

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.

Našli jste v článku chybu?