-
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.1 Úvod - Správa verzí
Tato kapitola pojednává o tom, jak se systémem Git začít. Nejdříve si vysvětlíme něco o původu nástrojů pro správu verzí, poté se budeme věnovat tomu, jak spustit systém Git ve vašem počítači, a nakonec se podíváme na to, co musíme nastavit, abychom s ním mohli začít pracovat. Na konci kapitoly byste měli rozumět tomu, proč tady Git je, proč byste jej měli používat a měli byste být na jeho používání připraveni.
Správa verzí
Co je to správa verzí a proč by vás měla zajímat? Správa verzí je systém, který zaznamenává změny souboru nebo sady souborů v čase tak, abyste se mohli později k určité verzi vrátit. V této knize jsou jako příklady souborů použity zdrojové texty programů, avšak ve skutečnosti lze správu verzí použít pro libovolný typ souborů.
Pokud jste grafik nebo návrhář webů a chcete uchovávat všechny verze obrázku nebo rozložení stránky (což jistě chtít budete), je rozumné, když budete systém pro správu verzí (VCS z anglického Version Control System) používat. Umožní vám vrátit soubory zpět do předchozího stavu, vrátit celý projekt do předchozího stavu, porovnávat změny provedené v průběhu času, zjistit, kdo naposledy upravil něco, co nyní možná způsobuje problémy, kdo a kdy vytvořil diskutabilní část a mnoho dalšího. Používáte-li systém pro správu verzí a něco se pokazí, nebo přijdete o soubory, můžete se z toho snadno dostat. To vše navíc získáte jen při velmi malém zvýšení režie.
Lokální systémy správy verzí
Mnoho uživatelů realizuje správu verzí tak, že zkopírují soubory do jiného adresáře (pokud jsou chytří, dají adresáři jméno podle data a času). Takový přístup je velmi častý, protože je jednoduchý, ale je také velmi náchylný k chybám. Člověk snadno zapomene, v kterém adresáři se právě nachází, a nedopatřením začne zapisovat do nesprávného souboru, nebo kopírováním přepíše soubory, které přepsat nechtěl.
Aby k těmto potížím nedocházelo, vyvinuli programátoři už dávno lokální systémy pro správu verzí. Byly založeny na jednoduché databázi, která uchovávala všechny změny souborů zařazených do správy revizí.
![Diagram lokální správy verzí.](png/local.png)
Jedním z oblíbených nástrojů pro správu verzí byl systém zvaný RCS, který je ještě dnes distribuován s mnohými počítači.
Dokonce i populární operační systém Mac OS X obsahuje po nainstalování vývojářských nástrojů (Developer Tools) příkaz rcs
.
RCS je založen na uchovávání sad záplat (tj. rozdílů mezi podobami souborů), uložených na disku ve speciálním formátu. Poskládáním záplat může později znovu získat podobu libovolného souboru v libovolném čase.
Centralizované systémy správy verzí
Dalším velkým problémem, s nímž se uživatelé potýkají, je potřeba spolupráce s vývojáři pracujícími na jiných počítačích. Pro vyřešení tohoto problému byly vyvinuty tzv. centralizované systémy pro správu verzí (CVCS z anglického Centralized Version Control System). Tyto systémy, jako je CVS, Subversion a Perforce, používají jeden server, který uchovává všechny verzované soubory, a více klientů, kteří umí soubory z centrálního místa získat. Tento koncept správy verzí byl po dlouhá léta považován za standard.
![Centralizovaná správa verzí.](png/centralized.png)
Toto uspořádání nabízí mnoho výhod, zejména v porovnání s lokálními systémy pro správu verzí. Všichni například do určité míry vědí, co na projektu dělají ostatní účastníci. Administrátoři mají přesnou kontrolu nad tím, co kdo může dělat. A správa centrálního systému pro správu verzí je mnohem jednodušší, než potýkání se s lokálními databázemi na jednotlivých počítačích.
Avšak i tato koncepce má závažné nedostatky. Tím nejkřiklavějším je kolaps po výpadku jediného místa, kterým je centrální server. Pokud takový server na hodinu vypadne, pak během této hodiny nelze spolupracovat vůbec, nebo přinejmenším není možné ukládat změny ve verzích souborů, na nichž uživatelé právě pracují. A dojde-li k poruše pevného disku, na němž je uložena centrální databáze, a disk nebyl správně zálohován, ztratíte úplně vše — celou historii projektu, s výjimkou souborů aktuálních verzí, jež mají uživatelé v lokálních počítačích. Lokální systémy pro správu verzí trpí stejným problémem. Kdykoliv máte celou historii projektu uloženou na jednom místě, riskujete, že přijdete o vše.
Distribuované systémy správy verzí
V tomto místě přicházejí ke slovu distribuované systémy správy verzí (DVCS z anglického Distributed Version Control System). V distribuovaných systémech pro správu verzí (jako jsou Git, Mercurial, Bazaar nebo Darcs) klient nestahuje pouze nejnovější verzi souborů (tzv. snímek, anglicky snapshot), ale zrcadlí celý repozitář. Pokud v takové situaci dojde ke kolapsu serveru a pokud jej tyto systémy využívaly, můžeme obsah serveru obnovit zkopírováním repozitáře od libovolného uživatele. Každý klon je ve skutečnosti úplnou zálohou všech dat.
![Diagram pro distribuovaný systém správy verzí.](png/distributed.png)
Mnoho z těchto systémů navíc bez větších obtíží pracuje i s několika vzdálenými repozitáři, takže můžete v rámci jednoho projektu různým způsobem spolupracovat s různými skupinami lidí najednou. Díky tomu lze zavést několik typů pracovních postupů, které nejsou v centralizovaných systémech možné — jako jsou například hierarchické modely.