-
1. Úvod
- 1.1 Správa verzí
- 1.2 Stručná historie systému Git
- 1.3 Základy systému Git
- 1.4 Příkazový řádek
- 1.5 Instalace systému Git
- 1.6 První nastavení systému Git
- 1.7 Získání nápovědy
- 1.8 Shrnutí
-
2. Základy práce se systémem Git
-
3. Větve v systému Git
- 3.1 Větve v kostce
- 3.2 Základy větvení a slučování
- 3.3 Správa větví
- 3.4 Postupy při práci s větvemi
- 3.5 Vzdálené větve
- 3.6 Přeskládání
- 3.7 Shrnutí
-
4. Git na serveru
- 4.1 Protokoly
- 4.2 Zprovoznění Gitu na serveru
- 4.3 Generování veřejného klíče SSH
- 4.4 Nastavení serveru
- 4.5 Démon Git
- 4.6 Chytrý HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Možnosti hostování u třetí strany
- 4.10 Shrnutí
-
5. Distribuovaný Git
- 5.1 Distribuované pracovní postupy
- 5.2 Přispívání do projektu
- 5.3 Správa projektu
- 5.4 Shrnutí
-
6. GitHub
-
7. Git Tools
- 7.1 Revision Selection
- 7.2 Interactive Staging
- 7.3 Stashing and Cleaning
- 7.4 Signing Your Work
- 7.5 Searching
- 7.6 Rewriting History
- 7.7 Reset Demystified
- 7.8 Advanced Merging
- 7.9 Rerere
- 7.10 Ladění v systému Git
- 7.11 Submodules
- 7.12 Bundling
- 7.13 Replace
- 7.14 Credential Storage
- 7.15 Shrnutí
-
8. Customizing Git
- 8.1 Git Configuration
- 8.2 Atributy Git
- 8.3 Git Hooks
- 8.4 An Example Git-Enforced Policy
- 8.5 Shrnutí
-
9. Git a ostatní systémy
- 9.1 Git as a Client
- 9.2 Migrating to Git
- 9.3 Shrnutí
-
10. Git Internals
- 10.1 Plumbing and Porcelain
- 10.2 Git Objects
- 10.3 Git References
- 10.4 Balíčkové soubory
- 10.5 The Refspec
- 10.6 Přenosové protokoly
- 10.7 Správa a obnova dat
- 10.8 Environment Variables
- 10.9 Shrnutí
-
A1. Appendix A: Git in Other Environments
- A1.1 Graphical Interfaces
- A1.2 Git in Visual Studio
- A1.3 Git in Eclipse
- A1.4 Git in Bash
- A1.5 Git in Zsh
- A1.6 Git in Powershell
- A1.7 Shrnutí
-
A2. Appendix B: Embedding Git in your Applications
- A2.1 Command-line Git
- A2.2 Libgit2
- A2.3 JGit
-
A3. Appendix C: Git Commands
- A3.1 Setup and Config
- A3.2 Getting and Creating Projects
- A3.3 Basic Snapshotting
- A3.4 Branching and Merging
- A3.5 Sharing and Updating Projects
- A3.6 Inspection and Comparison
- A3.7 Debugging
- A3.8 Patching
- A3.9 Email
- A3.10 External Systems
- A3.11 Administration
- A3.12 Plumbing Commands
1.3 Úvod - Základy systému Git
Základy systému Git
Co že to vlastně Git v jádru je? Pochopení této podkapitoly je důležité, protože pokud porozumíte, co Git je a na jakých základech pracuje, bude pro vás i jeho efektivní používání mnohem snadnější. Při seznamování s Gitem se pokuste vyčistit mysl od věcí, které možná znáte z jiných systémů pro správu verzí, jako jsou Subversion a Perforce. Při jeho používání se tím vyhnete určitým zmatkům. Ačkoli je uživatelské rozhraní velmi podobné jiným systémům, Git uvažuje o ukládaných informacích velmi odlišně. Pochopení těchto rozdílů vám pomůže předejít nejasnostem, které by mohly při používání Gitu vzniknout.
Snímky, nikoli rozdíly
Hlavním rozdílem mezi systémem Git a všemi ostatními systémy pro správu verzí (včetně Subversion a spol) je způsob, jakým Git o datech uvažuje. Většina ostatních systémů ukládá informace jako seznamy změn souborů. Tyto systémy (CVS, Subversion, Perforce, Bazaar atd.) chápou uložené informace jako sadu souborů a změn každého z těchto souborů v čase.
Git o ukládání dat tímto způsobem neuvažuje. Místo toho Git o datech uvažuje jako o sadě snímků miniaturního systému souborů. Pokaždé, když v systému Git zapíšete (commit[1]) stav projektu, v podstatě „vyfotí“, jak vypadají všechny vaše soubory v daném okamžiku, a uloží odkaz na tento snímek. Pokud se soubor nezměnil, pak ho Git v zájmu efektivnosti znovu neukládá, ale jen se odkáže na předchozí identický soubor, který už byl uložen. Git o svých datech uvažuje spíše jako o sérii snímků.
Jde o důležitý rozdíl mezi systémem Git a téměř všemi ostatními systémy pro správu verzí. Git díky tomu znovu zkoumá skoro každý aspekt správy verzí, který většina ostatních systémů okopírovala z předchozí generace. Díky tomu Git vypadá (spíše než jiné systémy pro správu verzí) jako malý souborový systém, nad kterým pracuje sada neuvěřitelně výkonných nástrojů. Některými výhodami, které získáme při tomto uvažování o datech, se budeme zabývat při výkladu větvení v kapitole Větve v systému Git.
Téměř každá operace je lokální
Většina operací v systému Git vyžaduje ke své činnosti pouze lokální soubory a zdroje. Obecně platí, že informace z jiných počítačů v síti nejsou potřebné. Pokud jste zvyklí pracovat s centralizovanými systémy správy verzí, kde je většina operací poznamenána latencí sítě, patrně vás při práci s Git napadne, že mu bohové rychlosti dali do vínku nadpřirozené schopnosti. Protože máte celou historii projektu uloženou přímo na svém lokálním disku, probíhá většina operací takřka okamžitě.
Pokud například chcete procházet historii projektu, Git kvůli tomu nemusí vyhledávat informace na serveru — načte je jednoduše přímo z vaší lokální databáze. Znamená to, že se historie projektu zobrazí téměř hned. Pokud si chcete prohlédnout změny provedené mezi aktuální verzí souboru a týmž souborem před měsícem, Git vyhledá měsíc starý soubor a provede lokální výpočet rozdílů, aniž by o to musel žádat vzdálený server nebo stahovat starší verzi souboru ze vzdáleného serveru a poté provádět lokální výpočet.
To také znamená, že je jen velmi málo operací, které nemůžete provádět offline nebo bez připojení k VPN. Jste-li v letadle nebo ve vlaku a chcete pokračovat v práci, můžete beze všeho zapisovat nové revize. Ty odešlete až po opětovném připojení k síti. Jestliže přijedete domů a zjistíte, že VPN klient nefunguje, stále můžete pracovat. V mnoha jiných systémech je takový postup nemožný nebo přinejmenším obtížný. Například v systému Perforce toho lze bez připojení k serveru dělat jen velmi málo. V systémech Subversion a CVS můžete sice upravovat soubory, ale nemůžete zapisovat změny do databáze (neboť ta je offline). Možná to vypadá jako maličkost, ale divili byste se, jak velký je v tom rozdíl.
Git udržuje integritu
Než se v Gitu cokoli uloží, nejdříve se z toho vypočítá kontrolní součet, který se pak používá k odkazu na uložená data. To znamená, že není možné změnit obsah jakéhokoli souboru nebo adresáře, aniž by o tom Git nevěděl. Tato funkčnost je do Gitu zabudována na nejnižších úrovních a je nedílnou součástí jeho filosofie. Nemůže tak dojít ke ztrátě informací při přenosu dat nebo k poškození souboru, aniž by to Git byl schopen zjistit.
Pro vytváření kontrolních součtů používá Git mechanismus zvaný SHA-1. Jde se o řetězec o 40 hexadecimálních znacích (0–9, a–f) vypočítaný na základě obsahu souboru nebo adresářové struktury systému Git. Otisk SHA-1 může vypadat například takto:
24b9da6552252987aa493b52f8696cd6d3b00373
S těmito otisky se budete setkávat v Gitu všude, protože je používá opravdu často. Git vlastně ve své databázi nic neukládá podle názvu souboru, ale podle otisku jeho obsahu.
Git obvykle jen přidává data
Pokud v Gitu provádíte nějaké akce, pak téměř všechny z nich data do databáze pouze přidávají. Přimět systém, aby udělal něco, co nelze vzít zpět, nebo aby smazal jakákoli data, je velice obtížné. Stejně jako v jiných systémech pro správu verzí můžete ztratit nebo poničit úpravy, které ještě nebyly zapsány. Jakmile však snímek zapíšete do Gitu, je téměř nemožné ho ztratit, zvlášť pokud databázi pravidelně odesíláte (push) do jiného repozitáře.
Díky tomu je práce s Gitem radostí, protože víme, že můžeme experimentovat bez nebezpečí závažného poškození hotových věcí. Podrobnější informace o tom, jak Git ukládá data a jak lze obnovit zdánlivě ztracenou práci, najdete v podkapitole Návrat do předchozího stavu.
Tři stavy
A nyní pozor. Pokud chcete dále hladce pokračovat ve studiu Gitu, budou pro vás následující informace stěžejní. Git používá pro spravované soubory tři základní stavy: zapsáno (committed), změněno (modified) a připraveno k zapsání (staged). Zapsáno znamená, že jsou data bezpečně uložena ve vaší lokální databázi. Změněno znamená, že v souboru byly provedeny změny, avšak soubor ještě nebyl zapsán do databáze. Připraveno k zapsání znamená, že jste změněný soubor v jeho aktuální verzi určili k tomu, aby byl zapsán do dalšího snímku (commit snapshot).
Z toho vyplývá, že projekt je v systému Git rozdělen do tří hlavních částí: adresář systému Git (Git directory), pracovní adresář (working directory) a oblast připravených změn (staging area).
Adresář Git je místo, kde Git uchovává metadata a databázi objektů vašeho projektu. Je to nejdůležitější část systému Git a zároveň je to adresář, který se zkopíruje, když klonujete repozitář z jiného počítače.
Pracovní adresář obsahuje lokální kopii jedné verze projektu. Tyto soubory jsou vytaženy ze zkomprimované databáze v adresáři Git a umístěny na disk, kde je můžete používat nebo upravovat.
Oblast připravených změn je soubor, většinou uložený v adresáři Git, který obsahuje informace o tom, co bude obsahovat příští objekt revize (commit[2]). Někdy se setkáme s označením „index“, ale běžně se používá i pojem oblast připravených změn (staging area).
Základní pracovní postup vypadá v Gitu následovně:
-
Změníte soubory ve svém pracovním adresáři.
-
Soubory připravíte k zapsání tak, že vložíte jejich snímky do oblasti připravených změn.
-
Provedete zápis (commit), který vezme soubory nacházející se v oblasti připravených změn, a tento snímek trvale uloží do adresáře Gitu.
Nachází-li se konkrétní verze souboru v adresáři Gitu, je soubor ve stavu „zapsaný“. Pokud byl soubor upraven a přidán do oblasti připravených změn, je ve stavu „připraven k zapsání“. A pokud byl vůči stavu v databázi upraven, ale nebyl připraven k zapsání, je ve stavu „změněný“. V kapitole Základy práce se systémem Git se o stavech souborů dozvíte více. Naučíte se, jak jich můžete využívat, nebo jak můžete stav „připraven k zapsání“ úplně přeskočit.
commit
. V grafických nástrojích bývá zobrazován jako bod (tečka, kulička, hvězdička). Pojem revize má význam spíš abstraktnější, ale též vyjadřující stav projektu (bez důrazu na způsob uložení nebo znázornění). Pojem revize má v souvislosti se systémy správy verzí své historické kořeny — viz zmíněný systém RCS (Revision Control System). Je to pravděpodobně rozumný jednoslovný český pojem, kterým se dá nahradit jednoslovné vyjádření commit. V situacích vyžadujících přesnější představu budu používat raději dvouslovný „objekt revize“