Třetí důvod proč zvolit Git : Decentralizace

Decentralizace

První článek našeho seriálu o Gitu jsme začali pozastavením nad tím, že „lidé od počítačů“ jsou paradoxně často konzervativní a nedůvěřiví k „novotám“. Podobně důležitým rozhodovacím faktorem je určitá obava ze ztráty kontroly. V případě verzovacích systémů je to ztráta kontroly nad hierarchií uživatelů, nad systémem oprávnění, a především nad jedním, autoritativním repositářem, v němž se skrývá „jedna pravda“, a žádná není nikde „bokem.“

Ale minulé století přineslo velký rozpad centralizovaných hodnotových systémů. Sigmund Freud ukázal, že lidskou duši nedefinuje „jeden příběh“ a po něm dekonstruktivisté ukázali, že text nemá jeden autoritativní smysl. A s velkým zpožděním decentralizace přichází i do „světa počítačů“; katalyzátorem je přitom, tak jako v případě většiny dalších změn, příchod internetu a webu.

Jedním z příkladů může být protokol BitTorrent, který otočil na hlavu tezi „čím více lidí stahuje nějaký soubor, tím pomalejší je stahování“. Rapidně rostoucí popularita decentralizovaných, nerelačních databází a key:value úložišť, která je motivována právě problémy se škálovatelností a flexibilitou tradičních databází, chystá podobnou revoluci ve vývoji pro web.

Co tedy znamená, že Git je distribuovaný, resp. decentralizovaný verzovací systém? Především to, že každá kopie repositáře je doslova jeho klonem, tedy plnohodnotným repositářem, který může technicky vzato kdykoliv nahradit jiný. Obsahuje celou historii, všechny publikované větve a tagy. Některý repositář samozřejmě může být a často bývá „centrální“ a slouží tedy ke sdílení mezi členy týmu, jak je obvyklé při používání centralizovaného verzovacího systému. Je to ale pouhá konvence a možností, jak si data vyměňovat, je mnohem více.

To, že každá kopie repositáře je dokonalým klonem, má radikální důsledky zejména pro zálohování: neexistuje pověstné „jedno zranitelné místo“ (single point of failure), které je třeba střežit jako oko v hlavě. V případě poškození „centrálního“ repositáře jej prostě smažeme, nahradíme jiným a chybějící data doplníme z ostatních klonů. Zálohování repositáře můžeme přitom provést i skrze infrastrukturu Gitu: při každé aktualizaci repositáře data odešleme příkazem git push do repositáře záložního, např. díky hookům.

Mnohem citelnějším důsledkem je ale to, že většina práce probíhá v lokální kopii repositáře. Kromě výměny revizí s ostatními Git nekomunikuje se vzdáleným repositářem: pokud je tedy vzdálený repositář nedostupný, mohu relativně dlouho v repositáři dále pracovat.

Pokud vám tedy vadí, že nemůžete prohlížet historii nebo commitovat ve vlaku z Brna do Prahy, decentralizované verzovací systémy vám otevřou úplně jiné možnosti. Platí to samozřejmě nejen pro „žádné připojení“, ale i pro „slabé připojení“ — tedy pokud vám commitování přes GPRS nepřijde jako zajímavé dobrodružství.

Nedostupnost repositáře ale nemusí být způsobena jen na mé straně, jak ji popisují příklady s vlaky a letadly. V praxi bývá často způsobena výpadkem konektivity na straně serveru s repositářem: „nejde repo, běžte domů“. Pokud používáte decentralizovaný verzovací systém, můžete velmi snadno nahradit „centrální“, sdílený repositář jiným. V závislosti na vaší infrastruktuře a potřebách tak můžete učinit přesunem repositáře na jiný server, zřízením dočasného sdíleného repositáře na libovolném serveru, kam mají ostatní SSH přístup, domluvou, že „centrální“ repositář je teď na chvíli „u Františka“, nebo prostým rozhodnutím, že synchronizaci uděláme zítra, „až to zase půjde“.

Z pohledu každodenní práce je ale nejvýznamnějším důsledkem úplně jiný rozměr: rychlost. Díky tomu, že pracujeme v lokálním repositáři, je většina operací daleko rychlejší než při práci v centralizovaných systémech, protože nedochází ke komunikaci přes síť. Rychlost je přitom kumulativní veličina: pět sekund může být docela málo, ale pokud trvá pět sekund operace, kterou dělám několikrát za čtvrthodinku, začne to hodně vadit. Navíc dochází k mentálnímu bloku: mám tendenci se takovým operacím vyhýbat. V Gitu probíhá prohlížení historie, práce s větvemi a další operace v řádu milisekund.

Tím, že práce probíhá lokálně, ale získáváme ještě jinou výhodu pro každodenní práci: tou je právě soukromá povaha repositáře. Dokud výslovně neřekneme „tohle pošli na server“, vše je jen lokálně a „bokem“. Už jen tento fakt je pro mnoho vývojářů hlavním důvodem přechodu na decentralizovaný verzovací systém (nejen tehdy, pokud vyvíjejí open source software). Pokud jste někdy jen trochu chtěli mít soukromé „pískoviště“, kam byste si po kouskách commitovali rozdělanou práci, zkoušeli bláznivá řešení, aniž by je hned viděli ostatní, a teprve potom se rozhodli, zda takové věci „pošlete dál“, Git a ostatní distribuované verzovací systémy vám opět otevřou úplně jiné možnosti práce.

Git tyto možnosti ještě násobí díky jeho schopnostem interaktivně upravovat historii, o nichž si povíme v následujícím článku. Zjednodušeně řečeno, umožňuje nám commitovat cokoliv, a teprve při publikování práce ji „učesat“ do prezentovatelné podoby.

Svoboda, nebo anarchie?

To někoho samozřejmě může už úplně vyděsit z pohledu „ztráty kontroly“. „Učesat“! Úpravy historie!! Soukromé „pískoviště“!!! Je to ale dáno zejména omezenou perspektivou. Může to znít překvapivě, software se ale nevyvíjí jen v korporacích s biometrickými čipovými kartami nebo firmách, které se takovými chtějí stát. Mnoho software vytvářejí jednotlivci či volně organizovaná společenství. Mnoho software se vytváří v přirozeně decentralizovaném prostředí, a jedním z hlavních příkladů je vývoj open source software (nejčastěji za přispění nejen „nadšenců“, ale i softwarových gigantů).

Git má toto prostředí „v genech“, neboť vzniknul pro správu verzí linuxového kernelu, jednoho z nejvýznamějších příkladů úspěchu F/OSS. Původní design Gitu je odvozen z workflow založené na výměně patchů e-mailem, jakkoliv bláznivé se vám to může zdát. (Mimochodem, dodnes Git nepotřebuje pro výměnu revizí přímé spojení s jiným repositářem, ale umožnuje revize začleňovat skrze přílohy e-mailů.)

Samotný fakt, že Git používají pro správu verzí velké či přímo gigantické projekty — ať již z pohledu počtu vývojářů, velikosti repositáře či jeho složitosti — jako je Ruby On Rails či Linux, je pádným důvodem, proč se nebát zvolit Git.

Při vývoji open source software je jedním z oblíbených oříšků otázka „kdo dostane klíče od repositáře?“ Okamžitě dělí přispěvatele do projektu na ty „s přístupem“ a na ty „bez přístupu“, vyžaduje obratné odpovídání na žádosti o „přístup“, složitou správu oprávnění všech těch „přístupů“, a tak dále. V Gitu je otázka „přístupu“ technicky a filosoficky vzato bezobsažná a nezajímavá. Protože každý repositář je dokonalým klonem, probíhá začleňování změn klidně tak, že správce projektu — nebo častěji správce části projektu, u větších repositářů — dostane upozornění na potenciálně zajímavou změnu ve forku repositáře, a pokud se mu taková zdá doopravdy, začlení ji do repositáře a „pošle dál“.

Podobně radikálně decentralizované workflow zpopularizoval mimo kruhy kernelových vývojářů, mezi běžnými smrtelníky, hlavní poskytovatel Git hostingu, server GitHub. Ten před rokem nabídl i efektivní grafické rozhraní pro správu příspěvků z „forků“ vašeho repositáře, jak vidíte z obrázku níže:

Právě poskytovatel Git hostingu GitHub se velkou měrou podílel na popularizaci Gitu, protože přinesl atraktivní a funkční rozhraní pro práci se sdílenými Git repositáři. Sám o sobě tvoří další z pádných důvodů, proč zvolit Git — přinejmenším pro open source software. Do softwarového vývoje totiž vnesl aspekty známé ze „sociálních platforem“ typu Facebook: možnost „sledovat“ zajímavé projekty nebo vývojáře, komentovat jednotlivé revize, vytvářet vlastní forky projektů a participovat tak na jejich vývoji.

Samozřejmě, že odvrácenou stranou takové „radikální decentralizace“ je, že u mnoha projektů dochází k „rozkolísání“ vývoje a k etapám, kdy není zcela jasné, který fork je vlastně „nejlepší“. Ale zároveň to znamená, že nikdo není vydán všanc nedostupnému nebo nerudnému správci projektu v open source variantě vendor lock-in. Mohu jednoduše udržovat vlastní fork a začleňovat do něj změny z upstream (originálního repositáře). Pokud budou změny užitečné i ostatním, mohou buď žádat správce originálního projektu o jejich začlenění, nebo jej postupně začít ignorovat a začít využívat náš fork, nebo si dokonce vytvořit svůj, „ještě lepší“.

Přestože nejběžnější je „pseudo-centralizované“ workflow, decentralizovaná povaha a flexibilita Gitu přináší možnosti různých variant a vylepšení — nebo zcela odlišných workflow, než které můžeme vymyslet a realizovat v centralizovaných verzovacích nástrojích. Krátké informace v češtině o několika typech workflow najdete v příslušné kapitole na stránce Proč je Git lepší než X nebo v prezentaci z Webexpo 2009. Souvislejší informace v angličtině pak v knize ProGit, která sama je překládána za pomoci decentralizované workflow.

Pro příklad varianty „centralizované“ workflow můžeme uvést kolegy ze společnosti Centrum Holdings, kteří pro vývoj interního CMS Ella využívají decentralizovanou povahu Gitu velmi silně. Každý pracuje v lokálním repositáři, a hotovou práci odesílá do interního sdíleného repositáře (potud funguje koncept „centrálního“ repositáře). Pomocí post-receive hooků se spouští integrační testy, a pokud projdou, revize se odešlou dále do repositáře na GitHubu. Interní repositář přitom obsahuje soukromé větve, které se na GitHub neodesílají a poskytují další funkcionalitu (kupříkladu při odeslání revizí do specifické větve se opět pomocí hooků spustí procesy, které ze zdrojových kódů zkompilují Debian balíčky).

I bez toho, abychom radikálně otočili pohled na svět, nám tedy decentralizovaná povaha Gitu může přinést velké výhody. Příště se podíváme na to, jak ji dále využít při úpravách a opravách historie.

(Autor děkuje Honzovi Královi za cenné připomínky a podněty k článku.)