Git je distribuovaný systém správy verzí.

Základním prvkem je pracovní adresář, obsahující nějaké soubory (které obykle tvoří náš projekt; soubory jsou samozřejmě v adresáři, případně jakýchkoliv podadresářích). Inicializací gitu v našem pracovním adresáři vytvoříme repozitář, což je adresář .git, obsahující mnoho souborů, mimo jiné i konfiguračních apod. Přidáme/komitneme (commit) naše soubory, následně prováděné změny, takže každý commit vytváří novou verzi - nový stav - ve kterém se naše soubory nacházejí. Z repozitáře je poté možné kdykoliv vytvořit pracovní adresář a to v takové verzi, kterou si přejeme.

Repozitář se vždy nachází v mém pracovním adresáři, tedy commity provádím do něj. Repozitář je potom možné synchronizovat s repozitářem na jiném počítači (serveru) a je tak možné efektivně spolupracovat ve více lidech a/nebo zálohovat svou práci.

Klasické označení “distribuovaný systém správy verzí” rozdělme jej na dvě části:

• Systém správy verzí - píšu důležitý dopis a dospěju k jeho první verzi. Večer ho dám přečíst manželce, která mi k tomu řekne své, přepíšu ho a mám druhou verzi. Ráno vstanu, znovu to přepíšu a mám třetí verzi. “Systém správy verzí” je to, co mi dovoluje tyto verze evidovat, prohlížet si co jsem mezi jednotlivýma verzema změnil, umožňuje vrátit k některé předchozí verzi, zvlášť poté co zase ukážu svou třetí verzi manželce.

• Distribuovaný - tento přídomek je zde hlavně proto, že v době kdy git spatřil světlo světa, byly všechny majoritní systémy správy verzí centralizované. Pokud ale nemáme zkušenost s těmi centralizovanými, nemusíme tomu věnovat zvlášť pozornost. V zásadě jde o to, že pro práci s gitem nepotřebujeme mít žádný server, zatímco ty centralizované ho nutně potřebovaly. Ty centralizované také hned předpokládaly, že na jednom projektu bude pracovat hodně lidí zaráz a nastavit to nebyla vůbec sranda. Git bude užitečný i jednomu člověku na malinkém projektu.

• data - adresář .git a jeho obsah (obvykle v adresáři svého projektu pokud není bare)
• aplikace - git v příkazovém řádku

• klikací aplikace ve windows (tedy grafické nádstavby nad základním gitem)
• ikonky v průzkumníku a řádky navíc po kliknutí pravým tlačítkem (tedy nádstavby nad grafickými nádstavbami)
• nějaký web, třeba github

• amend (česky pozměnit) - repair, modify, correct, alter jsou výrazy, kterým bychom asi rozumněli rovnou
• hook (česky háček) - jinde se setkávám s výrazy bind, event, trigger
• pre/post receive - mnou zažitým žargonem bych to nazval before/after receive
• staging area (česky přípravný prostor), index (ve starém žargonu) - takový před-commit, místo kde si chystám co za chvíli commitnu (své výhody to nesporně má)
• checkout (česky jít k pokladně) - slovům switch nebo load bych rozumněl hned

• VCS, (česky můžete potkat SSV) - Version control system, Systém správy verzí
• DVCS, DRCS - Distributed (re)vision control systems
• CVS, SVN - předchůdci Gitu

Návyky jak git používat, jak často commitovat atp., nejsou nijak diktovány, každý si to ve svém projektu stanoví sám.

Mé poznámky k výhodám Gitu - moje odpověď na devel.cz:

Hlavní výhodou Gitu pro spolupráci může být i rozdílnost přístupu jednotlivých programátorů. Některý bude dělat commity ojediněle, zato nebudou potřebovat pozdější opravy. Jiný bude chtít dělat commity často a v pozdějších commitech chybky vychytávat. Ten první pak bude z toho druhého na na nervy. V případě decentralizace může ten druhý commitovat u sebe jak je zvyklý a před pushnutím své práce do společného repozitáře to ještě může po sobě uhladit (commit a jeho pozdější tři „fix“ commity sloučit pěkně do jednoho…) a takto můžou společně vycházet a nebudou si muset nutit své odlišné pracovní postupy.

Proč by měli mít programátoři rozdílné pracovní postupy/návyky? Proč ne. Každému může sedět něco jiného a Git s tím počítá. Někdo svou práci „pre commituje“ jen do stage (dříve se prý používal název 'index', tedy příkazem `git add`) a commit dělá až ve chvíli, kdy se práce zdá být stabilní. Jiný v rámci sebe motivačního pracovního systému prostě commituje co chvilinku (tedy `commit -a`, stage přeskakuje).

Centralizovaný systém tuto volnost programátorům neumožní.

S tím související nevýhodou Gitu považuju, že je těžké se v něm zorientovat. Už proto, že ho spousta lidí používá různě a pak vzniká hodně různých návodů jak Git používat. Jeden vám doporučí větvit na všechno, další větvit trochu, další nevětvit skoro vůbec. Jeden mluví o stage (tedy postaru `indexu`) jako o kruciální záležitosti a druhý se o stage nezmiňuje vůbec jakoby neexistovala. Jeden doporučí commity upravovat, jiný vytahuje při podobných zmínkách svěcenou vodu, aby zahnal heretika. Další návod představuje instalaci protolu git a vydává to za Git. Někde vám zase představují Git tak, že prostě musíte mít nějaký veřejný repozitář, protože je to to nejdůležitější, zatímco jej vůbec mít nemusíte. Natož když člověk chce najít jak se s Gitem dělává deploy. Na nic z toho neexistuje jednoznačná odpověď „takto je to správně“. Každému může vyhovovat něco jiného. Proto člověk co s tím chce začít, aby pochopil všechny možnosti jak s tím pracovat a pak si vybral. V SVN skoro nemá na výběr, proto je to jednodušší se to naučit.

Nevýhodou SVN je také to, že když programátora napadne „udělám tento projekt, založím repozitář“ znamená složitou situaci, najít návod jak se to na tom serveru dělá a jak se to nastavuje na klientovi… V gitu je to jedna akce (jeden klik nebo jeden příkaz v terminálu).

Deploy aplikace pomocí gitu - moje odpověď na devel.cz