První důvod, proč zvolit Git: Neříká vám, jak máte pracovat

Lidé od počítačů jsou — možná docela paradoxně — velmi konzervativní. Téměř každá nová technologie se setkává s nedůvěrou, opovržením, někdy i otevřeným nepřátelstvím, ale v každém případě s postojem „a co mi to přinese?“ Jednou za čas ale přicházejí kvalitativní skoky, jako např. prosazení MVC frameworků do webového vývoje nebo RESTful architektura, které je obtížné ignorovat.

Jedním z takových skoků je i nástup decentralizovaných, resp. distribuovaných verzovacích systémů (DVCS), mezi něž patří Bazaar, Darcs, Mercurial — a Git, o němž je asi nejvíce slyšet. Je to možná i díky provokativní rétorice jeho tvůrce, Linuse Torvaldse, který tvrdí, že CVS a Subversion slouží jako proti-příklad verzovacího systému, nikoliv jako inspirace. Zmatek a (v podstatě oprávněná) nenávist vůči takovým novotám pak pochopitelně vzrůstá.

Podle reakcí na moji přednášku o Gitu na konferenci Webexpo se navíc zdá, že se měla jmenovat „Proč přejít (ze SVN) na Git“. Koncepce přednášky vědomě nebyla „pojďme si ukázat jak snadno se pracuje v TortoiseGit a jak využít Git jako SVN bez serveru“. Myslím, že málokomu se chce v sobotu ráno vstávat, aby se dozvěděl, že v Gitu lze committovat, mergovat a tak dále, a že, a teď pozor!!!, nemusíte u toho být připojení k internetu! Spíše jsem v ní chtěl ukázat jednoduchost i obrovskou flexibilitu Gitu, aby si každý mohl udělat názor sám. Zdá se však, že mnoha lidem chybí jasný přehled o tom, co je na tom Gitu vlastně tak úžasné a zajímavé, a proč by na něj — případně — měli „přejít“.

Cílem tohoto seriálu tedy není ani „úvod do Gitu“, ani naučit vás Git používat, přestože obsahuje popisy konkrétních postupů; to se můžete dozvědět a naučit např. z knihy Scotta Chacona Pro Git, dostupné zdarma v otevřené licenci. Jeho cílem je shrnout důvody, které vás mohou přesvědčit se na Git doopravdy zblízka podívat — nebo začít doopravdy využívat jeho možnosti. Začneme tím nejdůležitějším.

To jsi nejdřív měl…

Git neříká „to jsi nejdřív měl…“ Zřídit repositář, vytvořit branch, stáhnout si změny se serveru, uložit změny, … Začíná to už v úplném počátku: při vytváření repositáře. V Gitu můžeme v libovolném adresáři vytvořit nový repositář prostým příkazemgit init a je hotovo. Můžeme repositář vytvořit předtím, než něco uděláme, anebo, typicky, po chvilce patlání nějakého projektu, kdy si řekneme: „no, to vypadá zajímavě, to už by se vyplatilo verzovat“. Anebo, často: „tak a teď už vůbec nevím co dřív, radši si to budu po kouskách ukládat do Gitu, abych si mohl bezpečně zkoušet nápady“. Zřízení repositáře s sebou zkrátka nenese žádné obvyklé „tření“, žádnou námahu. Git umožňuje verzovat i obsah, kde se tomu člověk právě kvůli takové námaze vyhýbá: jako je třeba tento článek.

Už v tomto bodě se typicky „přesvědčovací diskuse“ zvrhávají v debatu o tom, že „já na to v Subversion mám shell script a …“ nebo „ale to já kliknu tadyhle pravým tlačítkem a …“ Ano, všechno jde všude nějak udělat: v PHP napodobit Ruby On Rails, „udělat to sedem a awk“, verzovat obsah pomocí „chytře“ pojmenovaných .tar.gz archivů, atd. Navíc, „v podstatě všechno“ lze naprogramovat v assembleru. Ale moc lidí to nedělá. Netrápí nás tedy, lze-li v A udělat v X i Y, ale spíše, jaký je — moderním slovníkem řečeno — „uživatelský prožitek“.

Některé Git konvertity totiž příkaz git init uvádí v nadšení. Mně osobně vždy šílenství se svnadmin create, svn import, atd. zdržovalo a rozptylovalo. Ale i oblíbený zvyk ukládat v Subversion nesouvisející projekty do jednoho repositáře a provádět partial checkout svědčí o tom, že git init může mnohým přinést úlevu.

Git je jednoduchý, nekomplikovaný — ne nadarmo je jeho oficiálním přízviskem stupid content tracker. Jednoduše řeší i oblíbený oříšek: nastavování souborů či složek, které se nemají verzovat. V Subversion si lze užít spoustu legrace se svn propedit svn:ignore, hledat které konkrétní soubory v kterých konkrétních složkách jsou verzovány, atd. Organizace ignorovaných souborů je jedním z důvodů, proč mnoho uživatelů SVN preferuje grafického klienta. Git tento problém řeší velmi jednoduše, pragmaticky a přitom elegantně: repositář obsahuje jediný soubor .gitignore, který je součástí repositáře a kde jsou informace o ignorovaném obsahu přehledně vypsány za pomoci důvěrně známých glob patterns:

config/database.ini       # Neverzuj soubor "database.ini" ve složce "config"
log/*.log                 # Neverzuj soubory s příponou "log" ve složce "log"
tmp/**/*                  # Neverzuj žádné soubory a složky ve složce "tmp"
!/tmp/special.txt         # VERZUJ soubor "special.txt" ve složce "tmp"

To je o moc přehlednější než cvičení se svn status, svn propedit svn:ignore tmp/, případně svn propget --recursive svn:ignore, že?

Git si tedy můžete zvolit proto, že je jednoduchý. Ale hodně věcí je „jednoduchých“: klikání v TortoiseSVN je také jednoduché. V Gitu vždy jednoduchost doplňuje obrovská flexibilita. Platí to např. v tomto případě: soubory .gitignore můžeme vložit i do jednotlivých složek — pravidla v nich uvedená pak mají vyšší prioritu — nebo můžeme mít jeden globální soubor s pravidly, zpravidla v $HOME/.gitignore. Pravidla specifická pro konkrétní repositář můžeme také ukládat do složky repositáře ( .git/info/exclude): nejsou pak součástí repositáře a platí lokálně. Záleží jen na nás, do jaké míry budeme chtít flexibility Gitu využít, než se nám zamotá hlava.

To už teď nemůžeš…

Když se tedy na otázku „to jsi nejdřív měl …“ podíváme z opačné strany, a zaměníme důraz na jednoduchost za flexibilitu, přístup Gitu bude podobně uvolněný. Mějme složitější příklad: zaplaveni endorfiny z povedeného kousku kódu se nám podaří do repositáře uložit konfigurační soubor s hesly. V ideálním případě do repositáře veřejného. (Následující příběh se zakládá na skutečných událostech.) Protože historie je v Gitu reprezentována pouze jako strom otisků stavu v čase, je pro Git relativně snadné takovou patálii vyřešit. Příkazgit-filter-branch projde celý strom revizí a daný soubor bez reptání odstraní:

$ git filter-branch --force --index-filter 'git update-index --remove configuration.ini' HEAD 

Samozřejmě, „řešení“ je částečné: hesla je dobré okamžitě změnit, neboť Git nemá žádný backdoor do kopií repositáře, které si již ostatní naklonovali, stáhli v ZIPu, atd. Jiným z typických příkladů použití příkazu git-filter-branch je např. změna osobních údajů autorů revizí. Podobné vlastnosti Gitu možná využijete jednou, dvakrát do roka. Ale samotná jejich možnost několikanásobně zvyšuje užitnou hodnotu verzovacího nástroje. Git si tedy můžete zvolit i proto, že je flexibilní, v duchu hesla „Jednoduché věci mají fungovat jednoduše a složité věci mají být možné“.

Důležitější než podobné speciality je však to, že svůj uvolněný přístup si Git zachovává i ve složitějších a častějších případech: neříká „to sis nejdřív měl dobře rozmyslet, co chceš committovat, než jsi udělal změny v pěti souborech najednou a teď tu hromadu chceš nějak inteligentně začlenit do repositáře“. Opět pomineme proti-argument, že takto se pracovat nemá, že si mám dobře rozmyslet na které části kódu chci pracovat, a že mám committovat pěkně po kouskách, prosím! Jenže v životě to tak vždy nechodí. V životě píšu kód na mnoha místech, tu doplním konfiguraci, tu opravím vzhled aplikace, tu refaktoruji kus kódu a o kousek dál přidám novou metodu nebo doplním test. A i kdyby mi pravidla nebo přesvědčení zakazovala tvořit takovým způsobem, mohu z principu ocenit nástroj, který mi žádný postup dopředu nevnucuje.

Právě pro takové případy, kdy chci odděleně uložit do repositáře změny, které mám v pracovním adresáři „promíchané dohromady“, přichází v Gitu vhod koncept indexu, resp. staging area. Git rozděluje proces uložení revize (commitu), který je v mnoha verzovacích systémech spojený, do dvou kroků: na přípravu obsahu k uložení do revize a na samotné uložení revize.

Mohu si tak pomocí příkazů typu git add public/*.js pohodlně připravit obsah, který chci do repositáře commitovat a uložení provést až následně a po ověření, že je vše správně. Ale nejenom to: v Gitu mohu jít pomocí příkazu git add --patch až na úroveň jednotlivého chunku, tedy několika řádků, které byly změněny v rámci jednoho souboru, případně až na úroveň konkrétního řádku. Nemusím tedy dopředu provádět různou ekvilibristiku (např. s diff  a patch --reverse) jen proto, abych mohl izolovaně uložit do repositáře část obsahu.

Dodejme, že Git disponuje velmi výkonným nástrojem git stash, který mi s přepínačem --keep-index umožní takto připravené změny ponechat, a ostatní dočasně odložit. Mohu tak např. spustit testy, jejichž průběh by (pozitivně či negativně) ovlivnily změny, které commitovat naopak (ještě) nechci.

Práce se staging area nám tedy především umožňuje zaznamenávat do repositáře atomické a smysluplné revize, a nemíchat v jedné revizi dohromady nesouvisející změny, případně ukládat revize typu „Zapomněl jsem přidat tenhle soubor“, „Aha, ještě tenhle soubor“ — to je častým nešvarem např. při používání SVN. Při používání Gitu nemá nikdo výmluvu, že něco „zapomněl“. Protože neplatí „to jsi nejdřív měl…“

V příštím pokračování se podíváme na to, zda Git zůstane podobně svobodomyslný i při důležitějších a závažnějších operacích: při práci s větvemi (branch) a jejich slučováním (merge).