Git 3

9. hodina DVOP WBB


Matěj Cajthaml — SSPŠ

©

Opakování

Jak zklonujeme repozitář z internetu?
Jak vytvoříme novou lokální větev v repozitáři?
Jak uložíme změny (tj. staged soubory)?
K čemu slouží značka HEAD?
Jak spojíme aktuální větev s jinou?

Gitové služby

GitLab

  • open-source
  • zdarma v limitovaném prostředí
  • velmi jednoduché na instalaci na vlastním zařízení
  • hezké UI, spousta funkcionalit

Github

  • closed-source
  • zdarma v limitovaném prostředí
  • nejznámější hostování Gitu
  • budeme používat právě jej

Issues

  • možnost zapisovat problémy / bugy / nápady pro jednotlivý projekt
  • možnost diskuze, přiřazení, značek, ...
  • mají vlastní číslo, které můžeme referovat v dalších částech (např. v commitech)
  • vždy konstruktivní a jasné požadavky
  • vlastní šablony

Projects

  • tabulka / Kanban board
  • plán věcí, jejich rozřazení pro lepší organizaci
  • automatizované akce
  • přidáváme issues nebo textové záznamy

Pro co byste používali Projects?

Pull requests

  • způsob omezení možnosti mergovat Váš repozitář s hlavním
  • požádáte, aby Vaše větev byla spojena s nějakou v repozitáři
  • diskuze, různé vlastnosti a možnosti review
  • jen někteří členové repozitáře mohou schválit

Releases

  • způsob vydání verze
  • automaticky se přikládá kód
  • můžete přiložit jakýkoliv soubor (např. pro stáhnutí)
  • ukazují se na hlavní stránce

Sémantické verzování

  • systém verzování projektů
  • tvořeno ze tří čísel, která se zvětšují
  • MAJOR.MINOR.PATCH
  • MAJOR — když nastala změna, která není zpětně kompatibilní
  • MINOR — když se přidá funkcionalita se zachováním zpětné kompatibility
  • PATCH — když se opravila chyba a zůstala zpětná kompatibilita
  • metadata / předběžné verze za verzí pomocí -*+*

Zjednodušené verzování

  • sémantické verzování je jen doporučení
  • často se dělají různé variace a zjednodušení
  • MAJOR — velká změna, přepsání aplikace, ...
  • MINOR — posun aplikace o velký krok
  • PATCH — malý posun, oprava chyb
  • důležité je, že verze lze seřadit

Verzování

Práce

Jsou verze správné dle sémantického verzování? Jaká je jejich další verze v MAJOR, MINOR a PATCH?

  • 12.3.0, 0.0.0
  • 0.0.1, 1.9.0
  • 9.9.9.9, 9.9.9
  • 23.4.0-beta+3
  • 23.4.0-alfabetatest

Jak lze verze seřadit?

Milestone

  • issues / projects
  • používá se pro označení věcí, které je potřeba splnit do nějakého milestone
  • např. verze nebo datum

Actions

  • spouštění akcí na omezeném prostředí / serveru
  • např. při push se projekt zkompiluje a nahraje na testovací verzi
  • lze spouštět ručně, vidět logy, ...
  • speciální nastavovací soubor
  • spousta komunitně spravovaných rozšíření

Repozitáře mohou být veřejné i soukromé a lze nastavovat, kdo jaké práva k přístupu má.

Veřejné repozitáře se často považují za open-source, tj. že se můžete podívat kód a dokonce jej i sami spustit. Vždy je ale důležitá licence, která má být uvedena.

V případě, že chcete do veřejných repozitářů přispívat, musíte si repozitář forknout (tj. nakopírovat jako vlastní) a nebo ho přidat jako vzdálený repozitář. Poté často tvoříte pull requests.

Přispívat do veřejných repozitářů musíte však často až po tom, co podepíšete smlouvu s tím, že Vaše práce je veřejná a v podstatě se vzdáváte nějakých práv (nelze smazat, ...).

Bez práv do veřejného repozitáře nelze pushovat, vytvářet větve a další věci.

Dokumentace

Dokumentace

  • pro projekty je důležité psát dokumentaci
  • jak v kódu, tak i různé návody
  • nějakou dokumentaci lze generovat přímo z kódu (Doxygen, ...)
  • Gitové nástroje dovolují pomocí markdownu jednoduché stránky ve Wiki

Readme

  • speciální soubor, který se vykreslí, když se navštíví repozitář (nebo jeho složka)
  • často markdown a jméno README.md
  • měl by popisovat co projekt je, jak jej použít, poskytnout odkazy, ...

Zásady práce s Gitem

Každý commit by měl být funkční (resp. spustitelný). Proč?

Zpráva commitu by měla reprezentovat, co se v commitu stalo, aby se dalo v historii jednoduše orientovat.

Je důležité znát firemní (nebo personální) styl práce, syntaxe a sémantiky. Názvy commitů by měli být konzistentní (např. v přítomném čase, anglicky, ...).

Historie repozitáře by se měla číst jako kniha a nezveřejňovat nedokončené části.

Nějaký koncept, který jsme si ukázali, nám toto rozbil — jaký?

Typy větví

  • obyčejný projekt má typy větví, které používá
  • stálé: master, develop, next
  • krátkodobé: issues, experimenty, nápady

Pro jednotlivé issues se tvoří větve, ve kterých se daná issue tvoří — názvy často referují na číslo a zkrácený název.

Např. issue#21: redirects are not consistent se pojmenuje jako 21-redirect.

Git klienti

Git klienti

  • software, program, webová stránka
  • zjednodušuje práci s repozitáři
  • často není nutné psát jakékoliv příkazy

Git klienti

  • GitKraken
  • GitHub Desktop
  • Sourcetree
  • v IDE
  • a další

Výhody

  • hezké prostředí
  • velmi hezky se zobrazuje historie a lze jednoduše vidět, co se změnilo
  • pro základní práci velmi intuitivní
  • často jednoduché merge conflicty
  • všechno to píše za Vás

Nevýhody

  • píše to všechno za Vás
  • často klikáte na něco, čemu vlastně nerozumíte
  • není dobré na pochopení
  • často není zdarma, různá podpora

Co jsme přeskočili?

  • vnitřnosti Gitu
  • hooks — možnost vytvořit akce při událostech rovnou v Gitu
  • co vlastně .git složka obsahuje
  • stash, blame, přidávání jednotlivých řádek jako staged
  • různé způsoby spojování změn — přeskládání (rebase)
  • resetování podrobněji (jak resetovat na nějaký commit, ...)
  • submoduly
  • a další...

Nejlepší způsob, jak se učit, je se učit za běhu, když něco děláte a Googlit!

Git nyní bude v různých samostatných i týmových pracích vyžadován a kontrolován.

Shrnutí

K čemu slouží značka HEAD?
Každý commit by měl být funkční (resp. spustitelný). Proč?
Jaké speciální funkčnosti má hlavní větev (main / master)?
Jak se liší MAJOR, MINOR a PATCH v sémantickém verzování?
K čemu slouží příkaz git log?

Děkuji za pozornost!

  • matej.cajthaml@ssps.cz
  • https://ssps.cajthaml.eu/