You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on May 2, 2019. It is now read-only.
Copy file name to clipboardExpand all lines: cs/01-introduction/01-chapter1.markdown
+7-7Lines changed: 7 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,7 +15,7 @@ Uživatelé často provádějí správu verzí tím způsobem, že zkopírují s
15
15
Aby se uživatelé tomuto riziku vyhnuli, vyvinuli programátoři už před dlouhou dobou lokální systémy VCS s jednoduchou databází, která uchovávala všechny změny souborů s nastavenou správou revizí (viz obrázek 1-1).
16
16
17
17
Insert 18333fig0101.png
18
-
Obrázek 1-1. Diagram lokální správy verzí
18
+
Figure 1-1. Diagram lokální správy verzí
19
19
20
20
Jedním z velmi oblíbených nástrojů VCS byl systém s názvem rcs, který je ještě dnes distribuován s mnoha 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. Tento nástroj pracuje na tom principu, že na disku uchovává ve speciálním formátu seznam změn mezi jednotlivými verzemi. Systém později může díky porovnání těchto změn vrátit jakýkoli soubor do podoby, v níž byl v libovolném okamžiku.
21
21
@@ -24,7 +24,7 @@ Jedním z velmi oblíbených nástrojů VCS byl systém s názvem rcs, který je
24
24
Dalším velkým problémem, s nímž se uživatelé potýkají, je potřeba spolupráce s dalšími pracovníky týmu. Řešení tohoto problému nabízejí tzv. centralizované systémy správy verzí (CVCS z angl. Centralized Version Control System). Tyto systémy, jmenovitě např. CVS, Subversion či Perforce, obsahují serverovou část, která uchovává všechny verzované soubory. Z tohoto centrálního úložiště si potom soubory stahují jednotliví klienti. Tento koncept byl dlouhá léta standardem pro správu verzí (viz obrázek 1-2).
25
25
26
26
Insert 18333fig0102.png
27
-
Obrázek 1-2. Diagram centralizované správy verzí
27
+
Figure 1-2. Diagram centralizované správy verzí
28
28
29
29
Nabízí ostatně mnoho výhod, zejména v porovnání s lokálními systémy VCS. Každý například – do určité míry – ví, co dělají ostatní účastníci projektu a administrátoři mají přesnou kontrolu nad jednotlivými právy. Kromě toho je podstatně jednodušší spravovat CVCS, než pracovat s lokálními databázemi na jednotlivých klientech.
30
30
@@ -35,7 +35,7 @@ Avšak i tato koncepce má závažné nedostatky. Tímto nejkřiklavějším je
35
35
V tomto místě přicházejí ke slovu tzv. distribuované systémy správy verzí (DVCS z angl. Distributed Version Control System). V systémech DVCS (např. Git, Mercurial, Bazaar nebo Darcs) uživatelé pouze nestahují nejnovější verzi souborů (tzv. snímek, anglicky snapshot), ale uchovávají kompletní kopii repozitáře (repository). Pokud v takové situaci dojde ke kolapsu serveru, lze jej obnovit zkopírováním repozitáře od libovolného uživatele. Každá lokální kopie (checkout) je plnohodnotnou zálohou všech dat (viz obrázek 1-3).
36
36
37
37
Insert 18333fig0103.png
38
-
Obrázek 1-3. Diagram distribuované správy verzí
38
+
Figure 1-3. Diagram distribuované správy verzí
39
39
40
40
Mnoho z těchto systémů navíc bez větších obtíží pracuje i s několika vzdálenými repozitáři, a vy tak můžete v rámci jednoho projektu spolupracovat na různých úrovních s rozdílnými skupinami lidí. Díky tomu si můžete vytvořit několik typů pracovních postupů, což není v centralizovaných systémech (např. v hierarchických modelech) možné.
41
41
@@ -62,12 +62,12 @@ Jak bychom tedy mohli Git charakterizovat? Odpověď na tuto otázku je velmi d
62
62
Hlavním rozdílem mezi systémem Git a všemi ostatními systémy VCS (včetně Subversion a jemu podobných) je způsob, jakým Git zpracovává data. Většina ostatních systémů ukládá informace jako seznamy změn jednotlivých souborů. Tyto systémy (CVS, Perforce, Bazaar atd.) chápou uložené informace jako sadu souborů a seznamů změn těchto souborů v čase – viz obrázek 1-4.
63
63
64
64
Insert 18333fig0104.png
65
-
Obrázek 1-4. Ostatní systémy ukládají data jako změny v základní verzi každého souboru.
65
+
Figure 1-4. Ostatní systémy ukládají data jako změny v základní verzi každého souboru.
66
66
67
67
Git zpracovává data jinak. Chápe je spíše jako sadu snímků (snapshots) vlastního malého systému souborů. Pokaždé, když v systému zapíšete (uložíte) stav projektu, Git v podstatě „vyfotí“, jak vypadají všechny vaše soubory v daném okamžiku, a uloží reference na tento snímek. Pokud v souborech nebyly provedeny žádné změny, Git v zájmu zefektivnění práce neukládá znovu celý soubor, ale pouze odkaz na předchozí identický soubor, který už byl uložen. Zpracování dat v systému Git ilustruje obrázek 1-5.
68
68
69
69
Insert 18333fig0105.png
70
-
Obrázek 1-5. Git ukládá data jako snímky projektu proměnlivé v čase.
70
+
Figure 1-5. Git ukládá data jako snímky projektu proměnlivé v čase.
71
71
72
72
Toto je důležitý rozdíl mezi systémem Git a téměř všemi ostatními systémy VCS. Git díky tomu znovu zkoumá skoro každý aspekt správy verzí, které ostatní systémy kopírovaly z předchozí generace. Git je tak z obyčejného VCS spíše povýšen na vlastní systém správy souborů s řadou skutečně výkonných nástrojů, jež stojí na jeho vrcholu. Některé přednosti, které tato metoda správy dat nabízí, si podrobně ukážeme na systému větvení v kapitole 3.
73
73
@@ -102,7 +102,7 @@ A nyní pozor. Pokud chcete dále hladce pokračovat ve studiu Git, budou pro v
102
102
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).
103
103
104
104
Insert 18333fig0106.png
105
-
Obrázek 1-6. Pracovní adresář, oblast připravených změn a adresář Git
105
+
Figure 1-6. Pracovní adresář, oblast připravených změn a adresář Git
106
106
107
107
V adresáři Git ukládá systém databázi metadat a objektů k projektu. Je to nejdůležitější část systému Git a zároveň adresář, který se zkopíruje, když klonujete repozitář z jiného počítače.
108
108
@@ -166,7 +166,7 @@ Existují dva jednoduché způsoby, jak nainstalovat Git v systému Mac. Tím ne
166
166
http://code.google.com/p/git-osx-installer
167
167
168
168
Insert 18333fig0107.png
169
-
Obrázek 1-7. Instalátor Git pro OS X
169
+
Figure 1-7. Instalátor Git pro OS X
170
170
171
171
Jiným obvyklým způsobem je instalace systému Git prostřednictvím systému MacPorts (`http://www.macports.org`). Máte-li systém MacPorts nainstalován, nainstalujte Git příkazem:
Copy file name to clipboardExpand all lines: cs/02-git-basics/01-chapter2.markdown
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -47,7 +47,7 @@ Nezapomeňte, že každý soubor ve vašem pracovním adresáři může být ve
47
47
Jakmile začnete soubory upravovat, Git je bude považovat za „změněné“, protože jste v nich od poslední revize provedli změny. Poté všechny tyto změněné soubory připravíte k zapsání a následně všechny připravené změny zapíšete. Cyklus může začít od začátku. Pracovní cyklus je znázorněn na obrázku 2-1.
48
48
49
49
Insert 18333fig0201.png
50
-
Obrázek 2-1. Cyklus stavů vašich souborů
50
+
Figure 2-1. Cyklus stavů vašich souborů
51
51
52
52
### Kontrola stavu souborů ###
53
53
@@ -619,7 +619,7 @@ Z téměř 20 000 revizí v historii zdrojového kódu Git zobrazí tento přík
619
619
Chcete-li použít graficky výrazněji zpracovaný nástroj k procházení historie revizí, možná oceníte Tcl/Tk program nazvaný `gitk`, který je distribuován spolu se systémem Git. Gitk je v zásadě grafická verze příkazu `git log` a umožňuje téměř všechny možnosti filtrování jako `git log`. Pokud do příkazového řádku ve svém projektu zadáte příkaz `gitk`, otevře se okno podobné jako na obrázku 2-2.
620
620
621
621
Insert 18333fig0202.png
622
-
Obrázek 2-2. Graficky zpracovaná historie v nástroji „gitk“
622
+
Figure 2-2. Graficky zpracovaná historie v nástroji „gitk“
623
623
624
624
V horní polovině okna vidíte historii revizí, doplněnou názorným hierarchickým grafem. Prohlížeč rozdílů v dolní polovině okna zobrazuje změny provedené v každé revizi, na niž kliknete.
0 commit comments