Jak na git díl 0

2 Git, Windows, Linux

Nultý díl z cyklu "Jak na git". Základní popis technologie, k čemu slouží, jaké funkce nabízí a proč by ji každý programátor měl znát a používat.

Jak na git díl 0

Tento článek patří do seriálu Jak na git. Ostatní články seriálu:


Co?

Git je systém pro verzování souborů vyvinutý Linusem Torvaldsem v roce 2005 pro vývoj jádra Linuxu. Jedná se o nástroj, který dokáže uchovávat jednotlivé verze souborů, efektivně zobrazovat rozdíly, slučovat změny více uživatelů a mnoho dalšího. V repozitáři nemusí být jen zdrojové kódy, často obsahuje také obrázky, či jiné binární soubory. U nich nedokáže zobrazit rozdíly, verzovat je však dokáže.

Git nebyl ale žádným průkopníkem. Již před ním existovalo nemálo podobných nástrojů jako CSV, SVN, BitKeeper, Darcs, Monotone a další. Přesto se git dostal na špici a je nyní nejpoužívanějším nástrojem pro správu verzí.

Většina určitě zná platformu GitHub, která je natolik rozšířená, že k ní přešel Google od svého code.google.com, Microsoft ze svého Codeplexu a tím to nekončí. Balíčkovací nástroje jako npm, composer, pypi, go get a další git používají. 

Ukázka zobrazení commitu v SourceTree

Proč?

Je jedno, jestli kód je psán jedním programátorem, nebo celým týmem. Git je vhodné používat v obou případech. Zde je pár příkladů, které git dokáže jednoduše řešit:

Graf commitů a větvení v SourceTree

Jak?

Git může klidně fungovat pouze lokálně a žádný vzdálený repozitář nepoužívat, to ale příliš časté řešení není. Vzdálený repozitář lze hostovat třeba na Bitbucketu, GitHubu, GitLabu a dalších. Git je původně napsán jako konzolová aplikace, přesto ale existuje mnoho GUI nástrojů jako GitKraken a SourceTree, ostatní třeba na git-scm.com. Osobně preferuji GitKraken, o kterém je na blogu také článek.

Pro mnoho lidí je git velkým strašákem, protože jeho možnosti jsou obrovské. Celá magie gitu ale spočívá jen v několika málo příkazech, které jsou popsány v následujících článcích. A pro běžné použití je ani není nutné znát všechny. Já také často do článků nahlížím při řešení méně častých problémů. Pokud se někdo i přesto rozhodne využívat grafické programy, terminologie je stále stejná a chování také.

Přejít na 1. díl tutoriálu Jak na git.


Umí git něco podstatného, co zde není popsáno? Měl bych určitě jistou informaci doplnit? Podělte se v komentářích s vlastními zkušenostmi

Přidat komentář

Položky označené * jsou povinné. Email nebude zveřejněn

Komentáře

Zajímavé hned po pátém dílu nultý díl :D

Každopádně dovoluji se nesouhlasit s bodem:
"Každý commit je vhodné ihned pushnout/nahrát na vzdálený repozitář".

Jak důvod uvádíš aby mohli spolupracovníci dále pracovat. Ale přece když bude 5 lidí a každý bude svůj jednotlivý commit (dejme tomu že za průměrný den udělám 6 průměrných commitů). To znamené že budeš mnohem více mergovat než kdyby si to poslal třeba po třech.

Další věc je oprava commitu. Z osobní zkušenosti vím, že pokud udělám commit a hned ho pushnu tak zpravidla hned při řešení dalšího tasku najdu soubor, který jsme commitnout zapomněl. Git to krásně řeší pomocí amend, ale všichni víme, že co je pushlé by se měnit nemělo.

Pokud push odložím na pozdější dobu, množství takto "zapomenutých" souborů se sníží a mám šanci s tím ještě něco dělat.

Díky, doplnil jsem poznámku.

Ano okamžitě nemusí být nejlepší. Osobní zkušenost ale říká, že jsem měl dokončit úkol, který kolega započal. Já musel čekal až to pushne, protože den předtím zapomněl.