Jak na git díl 0 - Co, proč, jak?

Pavel Windows, Linux, Git

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 - Co, proč, jak?

Jak na git díl 0: Co, proč, jak?
Jak na git díl 1.: git init, remote, config, clone, add, commit, push
Jak na git díl 2.: git status, log, checkout, reset
Jak na git díl 3.: git revert, stash, diff, clean
Jak na git díl 4.: git pull, git fetch, git branch, git merge
Jak na git díl 5.: git tag, git cherry-pick a opravy rozbitého gitu

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:

  • S gitem není problém se vrátit do předchozích verzí projektu, pokud byly průběžně tvořeny commity (atomické celky změn). Lze třeba dohledat, jak se daný problém vyřešil, kdy vznikl, kdo jej vyřešil apod. Ke každému commitu je možné napsat zprávu popisující provedené změny.
  • Při práci v týmu dokáže git velmi efektivně spojit soubory, takže i více vývojářů v týmu může v jednu chvíli pracovat s totožným souborem. V případě konfliktu git ponechá obě změny označené a vývojář může spojení provést ručně.
  • Větvení lze využít v mnoha případech. Nejčastějším je rozdělení na provozní a vývojovou větev. Dalším častým využitím je vývoj nových funkcionalit, kdy je potřeba se i průběžně vracet k aktuální verzi a opravovat chyby nebo provádět drobné úpravy v aktuální verzi. Stačí se přepínat mezi větvemi a git změní soubory do konkrétní podoby, v jaké byly v dané větvi.
  • Vrácení změn provedených dříve. Po přidání funkcionality, která je dočasná, se vytvoří commit. V době, kdy je potřebné změnu vrátit stačí provést revert commitu. I pokud v průběhu bylo provedeno několik jiných změn, git si s tím poradí a vrátí pouze změny provedené vybraným commitem. Ten může být klidně i spojení větví merge, dá se tak tedy vrátí změny provedené původně v několika commitech.
  • Přidávaní tagů pro jasné označení, kdy byla vydána daná verze softwaru. To především využívají balíčkovací nástroje, které umožňují stáhnout konkrétní verzi balíčku.
  • Pravidelné zálohování. Každý commit je vhodné "ihned" pushnout/nahrát na vzdálený repozitář. Zaprvé, aby i spolupracovníci mohli na projektu pokračovat, zadruhé, aby byla vytvořena záloha. Co znamená ihned je sporné, viz komentář od Vaška. Ne okamžitě v minutě, ale ani ne za 2 dny, nebo dokonce týden.

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ář

Právě odpovídáte na existující komentář. Zrušit

Komentáře

Václav Vaněk

http://vaclavvanek.cz 11.10.2017 13:57

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.

Odpovědět

Pavel

http://www.kutac.cz/blog/ 11.10.2017 17:19

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.

Novinky z blogu

Do Hyundai na interní prohlídku

Jak jsme zavítali do fabriky Hyundai Dymos v Nošovicích na jednu interní exkurzi. Absolvovali bezpečnostním školením, prošli si výrobní halu a také mohli zkusit vyrobit...

Další články