Začínáme s Git

Git je (podobně jako třeba mercurial) průkopníkem v novém přístupu ke správě verzí. Hlavním rysem distribuovaných systémů pro správu verzí (DVCS) je, že každá kopie repository je plnohodnotná a samostatná. To sice může být ze začátku složité na pochopení a občas to přidává práci, nicméně to s sebou přináší také nezanedbatelné výhody. Cílem tohoto článku je pomoci udělat první krůčky směrem ke Gitu a pochopit jak se s takovýmto systémem pracuje.

Když se řekne Git tak si asi každý vybaví Github. Github je zároveň poskytovatel hostingu pro Git a zároveň programátorská sociální síť. Jelikož nabízí hosting pro otevřené projekty zdarma, není lepšího místa, kde začít hrátky s Gitem.

Checkout versus Clone

Uživatelé Subversion jistě znají pojem checkout. U distribuovaných systémů má checkout trošku jiný význam a stažení repository ze serveru se nazývá clone. Pro moje testovací repository je clone úplně jednoduchý:

git clone git@github.com:honzasterba/gitest.git

V případě, že sis zrovna vytvořil nové repository na Githubu toto ale fungovat nebude, protože je repository docela prázdné (není tam ani žádná větev) a je tedy třeba ho znicializovat.

cd gitest
git init # vytvoří prázdné lokální git repository
touch README
git add README # přidá lokální soubor do dalšího commitu
git commit -m 'first commit' # lokální commit souboru
git remote add origin git@github.com:honzasterba/gitest.git
git push origin master

Add, commit a push

Poslední dva řádky víše jsem nechal bez komentáře záměrně, protože je třeba vysvětlit jednu základní odlišnost Gitu od například Subversion. Commit je lokální operace. Co to znamená? Jenom to, že když uděláš git commit tak se změny uloží jako revize do lokálního repository. K tomu, aby se změny dostaly na server, je třeba udělat push. V konečném důsledku to vypadá tak, že svoji práci můžeš postupně lokálně commitovat a následně udělat push a odeslat změny na server. Zjednodušený proces vypadá následovně:

1. práce a změny v souborech
2. git add <soubory které chci commitovat>
3. git commit
4. návrat do bodu 1. nebo pokračování
5. git push origin master

Celý push vypadá taky velmi komplikovaně, ale nic složitého na něm není. Origin je symbolické jméno, které jsme na začátku přiřadili našemu repository na serveru a může být ekvivalentně nahrazeno URL. Master je jméno větve do které se naše změny mají synchronizovat a jedná se taky o jmennou konvenci pro hlavní větev. Parametr s názvem větve je nepovinný (použije se aktuální větev), ale doporučovaný, aby se později předešlo omylům.

Pull

Opakem operace push je pull. Pull je dvoukroková operce, git nejdříve vytvoří lokální větev (branch) do které stáhne nové změny ze serveru a pak tuto větev (FETCH_HEAD) merguje do aktuální větve. Celý příkaz vypadá takto:

git pull origin master

Opět je třeba předat název repository a větve. Oba parametry se dají vynechat pokud git nakonfiguruješ tak aby si master doplnil automaticky.

Merge

Každý kdo používal jakýkoli VCS systém zná nončí můru jménem merge. Drtivou většinu mergování zvádá git automaticky a děje se v podstatě kdesi za oponou. Co ale v případě, že od doby, kdy jsi udělal poslední pull, někdo jiný pushnul svoje změny a tobě teď push nefunguje? Celý pproblém je v tom, že před pushnutím je potřeba mít lokální repository akuální, což znamené udělat pull:

git pull origin master

Občas ale dojde ke nofliktu dvou revizí. Někdo jiný pushne změny do douboru, který mám já u sebe lokálně změněný a je problém. V takovém případě se git pokusí udělat merge automaticky a když ani to neprojde tak je potřeba ho udělat ručně. Při konfliktu git nahlásí toto:

CONFLICT (content): Merge conflict in <cesta k souboru>
Automatic merge failed; fix conflicts and then commit the result.

Soubor je nutné ručně upravit a výsledný merge pak commitnout:

git add <cesta k souboru>
git commit

Při commitu pak git předvyplní commit message tak aby indikovala, že se něco mergovalo:

Merge branch 'master' of git@github.com:honzasterba/gitest

Následně už nic nebrání tomu svoje změny včetně přimergovaných změn kolegů poslat na server.

Súvisiace články

1. Démonické procesy a Rails
2. Přizpůsobivé pozadí
3. Refaktoring iterátoru
4. Démonické procesy v Ruby