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

Přinášíme vám první část pětidílného seriálu o tom, co vám může nabídnout verzovací systém Git. Budeme se v něm spolu s Karlem Minaříkem, propagátorem tohoto systému v ČR, věnovat jak obecným důvodům, tak okrajovým či unikátním vlastnostem Gitu. V dnešní části se zaměříme na svobodomyslnou povahu Gitu.

Seriál: Pět důvodů, proč zvolit Git (5 dílů)

  1. První důvod, proč zvolit Git: Neříká vám, jak máte pracovat 21.12.2009
  2. Druhý důvod proč zvolit Git: Snadné vytváření a slučování větví 28.12.2009
  3. Třetí důvod proč zvolit Git : Decentralizace 4.1.2010
  4. Čtvrtý důvod proč zvolit Git : Úpravy a opravy historie 11.1.2010
  5. Pátý důvod, proč zvolit Git : Zkušenosti uživatelů Gitu 18.1.2010

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é“.

Chcete-li se naučit efektivně využívat všechny možnosti Gitu, objednejte si od autora článku školení, nebo si rezervujte místo v kurzech na www.git-fu.cz.

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.

GITx5

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.

GITx5

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).

Karel Minařík navrhuje a programuje webové stránky a aplikace, poskytuje konzultace a školení v oblasti vývoje pro web a žije v Praze se svojí ženou a dvěma dcerami.

Věděli jste, že nám můžete zasílat zprávičky? (Jen pro přihlášené.)

Komentáře: 75

Přehled komentářů

MD Titulek
alblaho konzervatismus
Milan Re: konzervatismus
Liška Re: konzervatismus
Karel Minařík Re: konzervatismus
AraxoN spolupráca viacerých vývojárov
Aleš Roubíček Re: spolupráca viacerých vývojárov
Karel Minařík Re: spolupráca viacerých vývojárov
AraxoN Re: spolupráca viacerých vývojárov
Aleš Roubíček .gitignore vs. .svnignore
Karel Minařík Re: .gitignore vs. .svnignore
Petr Tesařík Re: .gitignore vs. .svnignore
Aleš Roubíček Re: .gitignore vs. .svnignore
Lukáš GIT IDE integrace
HKou Re: GIT IDE integrace
Rdm malý dotaz :)
Karel Minařík Re: malý dotaz :)
Bubak SVN v
Karel Minařík Re: SVN v
Bubak Re: SVN v
Karel Minařík Re: SVN v
Karel Minařík Re: SVN v
Matucha Re: SVN v
Karel Minařík Re: SVN v
František Kučera Mercurial
Karel Minařík Re: Mercurial
V.M. Re: Mercurial
uf Re: Mercurial
Karel Minařík Re: Mercurial
František Kučera Re: Mercurial
František Kučera Re: Mercurial
tom Re: Mercurial
Lukáš Re: SVN v
ijacek Re: SVN v
Karel Minařík Re: SVN v
vandrovnik Re: SVN v
Karel Minařík Re: SVN v
ijacek Re: SVN v
vandrovnik Re: SVN v
ijacek Re: SVN v
Jirka P Re: SVN v
Tomas Re: SVN v
Martin Michálek Konzervy od počítačů / GIT na Windows
Jan Kodera tohle vypadá dobře
Stepan Jednoduchost neni nejsilnejsi vlastnost Gitu
Karel Minařík Re: Jednoduchost neni nejsilnejsi vlastnost Gitu
Karel Re: Jednoduchost neni nejsilnejsi vlastnost Gitu
Sid Re: Jednoduchost neni nejsilnejsi vlastnost Gitu
Karel Minařík Re: Jednoduchost neni nejsilnejsi vlastnost Gitu
Jiří Landsman Re: Jednoduchost neni nejsilnejsi vlastnost Gitu
uf Re: Jednoduchost neni nejsilnejsi vlastnost Gitu
David Majda Re: Jednoduchost neni nejsilnejsi vlastnost Gitu
Renda Re: Jednoduchost neni nejsilnejsi vlastnost Gitu
David Majda Re: Jednoduchost neni nejsilnejsi vlastnost Gitu
tom Re: Jednoduchost neni nejsilnejsi vlastnost Gitu
Karel Minařík Re: Jednoduchost neni nejsilnejsi vlastnost Gitu
David Majda Re: Jednoduchost neni nejsilnejsi vlastnost Gitu
Karel Minařík Re: Jednoduchost neni nejsilnejsi vlastnost Gitu
Lukas Re: Jednoduchost neni nejsilnejsi vlastnost Gitu
tom slozky
Pavel Šimek commituji přání hezkých Vánoc
D3T Konzerva
Karel Minařík Re: Konzerva
D3T Re: Konzerva
Karel Minařík Re: Konzerva
lenin.power git je k nicemu
Karel Minařík Re: git je k nicemu
herne the hunter Re: git je k nicemu
fallanck Ke Gitu
David Grudl index area
Karel Minařík Re: index area
Borek Bernard Re: index area
Karel Minařík Re: index area
Borek Bernard Re: index area
Karel Minařík Re: index area
Zdroj: https://www.zdrojak.cz/?p=3139