Úvod do Gitu
Tento článek obsahuje úplné základy Gitu pro začátečníky. Nejprve si Git krátce představíme, poté si ukážeme nějaké základní příkazy pro nastavení a také ovládání. Nakonec si ukážeme co jsou to větve a jak s nimi pracovat.
Git obecně
Git je systém správy verzí (anglicky Version Control System – „VCS“). Je tedy systémem, který zaznamenává změny sledovaných adresářů a souborů v průběhu času. Takže se může uživatel například kdykoliv vrátit k původní verzi souboru, kterou někdy v minulosti napsal. Je to také nepostradatelný nástroj pro vývoj většího projektu v týmu. Systémů pro správu verzí existuje velká řada a dělíme je podle způsobu ukládání dat. Máme VCS lokální, centralizované a distribuované. Nejznámějšími představiteli centralizovaných systémů správy verzí jsou CVS a Subversion. Jak centralizovaný, tak i lokální systém správy verzí, uchovávají verzované soubory na jednom místě (buď u sebe v databázi na lokále, nebo na serveru) a my pracujeme s aktuální verzí, kterou jsme si stáhli. To má značné nevýhody: např. riziko výpadku disku (a možnou ztrátu dat) nebo to, že většina operací je značně zpomalena z důvodu častého dotazování serveru (např. prohlížení obsahu nějaké starší revize). Naopak u distribuovaných VCS má každý uživatel u sebe kompletní kopii repozitáře. Z toho plyne mnoho výhod, mezi kterými je například to, že při kolapsu serveru existují zálohy u všech nedávno aktivních uživatelů. Git se od ostatních známých systémů také liší možností práce offline. Programátor tak může např. pracovat v dopravním prostředku a poté, co přijede na místo s připojením k internetu, jen synchronizovat svojí práci. Z přítomnosti celého repozitáře také plyne to, že se některé operace staly lokálními – např. se urychlí procházení historie, protože už k tomu není potřeba žádná komunikace se serverem.
Princip Gitu
Na rozdíl od jiných VCS Git uchovává snímky, nikoliv rozdíly. To v praxi znamená, že Git každou revizi vlastně „vyfotí“ přesně ve stavu, v jakém zrovna je. Revizí rozumíme stav, ve kterém uložíme náš systém souborů (do kterého se můžeme později vrátit). Na soubory, které se od poslední revize nezměnily, uložíme v naší nové revizi pouze ukazatel. Pokud bychom přeci jen měli zájem o rozdíly mezi soubory jednotlivých revizí, Git je schopný je dopočítat.
Struktura Gitu
V jeho struktuře rozlišujeme tyto části:
- pracovní adresář (working directory) – Obsahuje soubory revize, na kterých pracujeme
- oblast připravených změn (staging area) – Soubory, které jsou připraveny k zápisu při vytvoření další revize
- adresář systému Git (Git directory) – Jednotlivé revize našeho projektu
Každá tato část obsahuje jiný druh souborů, které si dále popíšeme:
- Nesledované: Nejsou součástí posledního snímku repozitáře ani oblasti připravených změn. Mohou to být např. nějaké soubory z logování, které chceme mít ve stejné složce jako projekt, ale nechceme je sdílet s ostatními.
- Sledované:
- změněno(modified) – Soubor byl změněn,ale ještě se nebude zapisovat
- nezměněno(unmodified) – Soubor v pracovním adresáři, který jsme nijak neměnili
- připraveno k zapsání (staged) – Verze změněných souborů, které jsme označili k zapsání
- Zapsáno – Verze souborů bezpečně zapsané v naší lokální databázi
Základní příkazy Gitu
Nyní si ukážeme několik základních příkazů, které umožní s Gitem pracovat.
- $ git status – Ukáže status souborů v našem aktivním repozitáři (to je ten, ve kterém se zrovna nacházíme)
- $ git add <soubor> – Přidá soubor do sledovaných nebo připraví soubor k zapsání
Ignorované soubory:
Soubory, které nechceme sledovat a nechceme, aby nás na to Git upozorňoval ve statusu. Seznam takových souborů a adresářů zapíšeme do souboru .gitignore.
Nastavení Gitu:
- $ git config –global user.name „John Doe“ – Nastaví nám jméno, pod kterým budeme zapisovat revize
- $ git config –global user.email johndoe@exm.com – Nastaví nám email
- $ git config -list – kontrola nastavení
Vyvolání nápovědy:
Následující příkazy jsou ekvivalentní a slouží k vyvolání nápovědy z manuálové stránky pro příkaz z Gitu.
- $ git help <příkaz>
- $ git <příkaz> –help
- $ man git-<příkaz>
Odstraňování souborů:
- $ rm <soubor> – Smaže ho z adresáře, takže bude modified a pokud ho budete chtít z repozitáře skutečně smazat, tak je potřeba ho ještě přidat příkazem add do staged
- $ git rm <soubor> – Rovnou smaže soubor a vloží ho do staged sám (projeví se hned po commitu)
- $ git rm –cached <soubor> – Vyhodí soubor ze seznamu sledovaných souborů a nesmaže ho z disku
Přesouvání souborů:
- $ git mv <soubor> <novyNazev> – Vytvoří nový a smaže původní soubor
Commit revize:
- $ git commit – Po zadání se otevře editor s výzvou, abychom zadali komentář k revizi
- $ git commit -m „zpráva“ – Commitne rovnou se zprávou v uvozovkách
- $ git commit -a – Option “-a” znamená, že se do revize zapíší i soubory modified (nejen ty k zápsání)
Historie revizí:
- $ git log – Vypíše historie revizí v daném repozitáři
- $ git log -<číslo> – (např. $ git log -2 – vypíše poslední 2 revize)
- $ git log -stat – Statistiky změněných souborů: Kolik bylo vloženo a vymazáno řádek.
- Omezení logu:
- –since = od, –until = do
- — autor – Vyhledání autora
- — grep – Vyhledání klíčových slov v revizích
- Další filtry jsou např. –<soubor>, –<adresář> na konec příkazu značí jen revize týkající se daného souboru nebo adresáře
Přepsání revize:
Přepsání poslední revize se může hodit, když např. zapomeneme tzv. “addnout” soubor:
- $ git commit -m „puvodni commit“ – Tímto jsme commitnuli tu poslední revizi, do které jsme zapomněli přidat soubor
- $ git add zapomenuty_soubor – Zapomenutý soubor označíme k zapsání
- $ git commit -amend – Přepíšeme původní revizi
Větvení
Větvení je důležitá část Gitu, která nám umožňuje pracovat ve více lidech na jednom projektu. Nová větev projektu se také může hodit, když potřebujeme otestovat nějaký fix. Při vývoji tohoto fixu může být náš projekt nestabilní a proto ho vytváříme v jiné větvi a poté pouze namergujeme do naší staré větve. Níže si ve zkratce vysvětlíme co větve jsou, jak se vytvářejí, slučují a další důležité operace. Všechny uvedené obrázky byly převzaty z českého překladu knihy Pro Git, jejíž autorem je Scott Chacon (r. 2009, v češtině vydal CZ.NIC, z. s. p. o.).
Větev
Větev je ukazatel na nějakou revizi. Může to být např. ukazatel na naší aktuální revizi, na které pracujeme. Ty “zvláštní” kombinace čísel a písmen na obrázku (98ca9, 34ac2, f30ab) jsou tzv. hashe revize. Jsou to jednoznačné identifikátory jednotlivých revizí. Pokud známe hash revize, můžeme se na ní zpátky přesunout a pracovat na ní.
Vytvoření nové větve
Vytvoření nové větve provedeme příkazem $ git branch <nazevVetve>. Na obrázku vidíme výsledek tohoto příkazu: $ git branch testing – Právě pracujeme na větvi s názvem “hlavní větev” a vytvořili jsme novou větev s názvem “testing” (jelikož větev je vlastně ukazatel na revizi, tak “hlavní větev” a “testing” ukazují v tuto chvíli na stejné místo). 
V této části je důležité zmínit ukazatel HEAD. Ten určuje na které větvi se zrovna nacházíme. Vlastní ukazatel HEAD můžeme mít tedy v dané chvíli pouze jeden. Na následujícím obrázku ukazatel HEAD specifikuje, že jsme na “hlavní větvi” i když větev “testing” zrovna ukazuje na tutéž revizi. 
Přepnutí na jinou větev
Přepnutí na jinou větev provedeme pomocí $git checkout <nazevVetve>. Vezmněme si náš předchozí příklad a z “hlavní větve” se přepneme příkazem $git checkout testing na “testing” větev. Tím jsme vlastně přenastavili ukazatel HEAD tak, aby ukazoval na novou větev a pokud se teď rozhodneme commitnout, bude změna provedena na té druhé větvi. 
Nyní se v našem příkladě přepneme zpět na “hlavní větev” ($git checkout hlavni) a provedeme commit i tam. Výsledek si zobrazíme na následujícím obrázku: 
Slučování větví
Vývoj tedy může pokračovat na 2 různých větvích, ale časem dojdeme do situace, kdybychom je zase rádi sloučili. To uděláme tzv. mergem větví. Na obrázku vidíme příklad merge “hlavní větve” a větve “iss53”. Na “hlavní větvi” jsme provedli jeden commit a na “iss53” dva. V době kdy jsme Git o merge požádali jsme zrovna pracovali na “hlavní větvi” a proto se bude “iss53” větev “přilévat” do naší aktuální “hlavní větve”. Výsledek si můžeme prohlédnout na obrázku: 
Důležitá poznámkou k mergování je to, že Git merguje nejen na základě toho, jak vypadají oba slévané snímky revizí, ale také vezme do úvahy posledního společného předka těchto revizí. Na našem obrázku výše tedy merguje s ohledem na snímky C6,C5 a společného předka C2. Merge, který jsme si předvedli výše na obrázku, si nyní předvedeme pomocí příkazů řádky.
- Nejprve přepneme na hlavní větev, protože tam chceme, aby se výsledek “slil” – $ git checkout master
- Poté příkazem zajistíme, aby se do naší aktuální větve “namergovala” větev “iss53” – $ git merge iss53
- Nyní je vytvořen snímek C6 (viz obrázek) a proto můžeme smazat větev “iss53”. To provedeme pomocí $ git branch -d iss53
Konflikty vzniklé slučováním větví
Konflikt nám může nastat, např. pokud jsme s kolegou každý na jiné větvi modifikovali stejný soubor. Git při mergování těchto větví nebude vědět, jak s takovým souborem naložit. Řešení je v takovém případě ponecháno na uživateli, který merge pustil. Buď má možnost si soubor upravit sám (na základě toho, jak vypadaly slučované soubory) a změnu commitne, nebo vezme soubor z jedné či druhé slučované větve (v takovém případě se využijí příkazy s přepínači –theirs nebo –ours).
Vzdálené větve
Vzdálené větve jsou reference na stav větví ve vzdálených repozitářích, které nejde přesouvat. Název je ve formátu (vzdálený repozitář)/(větev). Odesílat vlastní větve na server můžeme pomocí jednoho z těchto příkazů:
- $ git push
- $ git push <server> <větev>
Pokud chceme přijmout větev a začlenit ji k sobě na lokál, provedeme to pomocí $ git pullVytvoření sledovací větve na ukazateli vzdálené větve:
- $ git checkout -b <větev> <server>/<větev>
- Je to tzv. sledovací větev – funguje např $ git push nebo $ git pull bez dalších parametrů
Reference na vzdálený server aktualizujeme příkazem $ git fetch a mazání vzdálené větve provedeme příkazem $ git push [vzdálený sever] :[větev]
Závěr
V článku jsme si ukázali všechno důležité pro začátek práce s Gitem. Pro další studium doporučuji nahlédnout do výše zmiňované knihy Pro Git od Scotta Chancona (dostupná i v českém vydání od CZ.NIC). Pokud byste měli k článku nějaký dotaz, napište mi na info@bcvsolutions.eu.
