Obsah

Git

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.

O gitu jinak

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

Git tvoří

Co někdo může nazývat gitem

Pojmy, které mi nebyly hned jasné

Různé související zkratky, pojmy

Práce s gitem

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.

Git vs. SVN

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).

Odkazy

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