Git

70. hodina MVOP WBF

Matěj Cajthaml — SSPŠ

©

Git

  • decentralizovaný systém
  • verzovací systém
  • určen pro práci na týmových projektech
  • využívá se i samostatně

Decentralizovanost říká, že git projekt můžete mít i u sebe na počítači a nikdo jiný k němu nemusí mít přístup.

Základní pojmy

  • repository = (typicky) jeden projekt, kompletní podoba práce
  • commit = ucelený balíček změn (přidání, odstranění souboru, ...) se zprávou
    • autor
    • zpráva změn
    • jsou ukládané historie, orientované
  • branch = část repozitáře, obvykle určen k části vývoje

Dva kroky

  • sdílení práce s ostatními je rozdělena na dva kroky

  • uložení práce do lokálního repozitáře (commit)
  • vyměněna práce se vzdáleným repozitářem (push a pull)

Git centralizovaně

  • přestože je git decentralizovaný, často se používá centralizovaně
  • potom existuje vdálený hlavní repozitář, který slouží jako server
  • propojení repozitáře je realizováno pomocí remote repozitářů

Služby

  • GitHub
  • GitLab
  • GitLab self-hosted
  • BitBucket

Celý git je založen na pár příkazech, které se používají v konzolové řádce.

Nástroje

  • GitKraken
  • GitHub Desktop
  • Sourcetree

Commity by měly být zřetelně pojmenované a říkat, co se změnilo. Neměly by popisovat každou změnu výčtem.

Commity mají obsahovat jednu ucelenou změnu, po které je projekt funkční.

Tedy, když se chceme vrátit k jakémukoliv commitu, bude projekt funkční.

Soubor .gitignore

  • určuje, jaké soubory se na git nikdy nepošlou
  • tyto kontroly provádí git při přidání (git add)
  • pro naše projekty to jsou:
    • node_modules
    • dist
    • package-lock.json

Branch

  • = větev změn
  • často používáme pro rozdělení práce více lidem
  • každý pracuje na jednotné změně a potom se větve sloučí (tzv. pull/merge request a merge)
  • hlavní větev bývá main či master

Jaký problém by mohl nastat při používání větví?

Merge conflict

  • když se soubor od větve změnil natolik, že nelze rozpoznat co má zůstat
  • poté je nutné určit co v souboru po spojení zůstane
  • doporučuji se vyhnout úpravám pomocí příkazů

Pull requesty se vytvářejí přímo na službě. Tyto pull requesty poté mohou ostatní členové komentovat, zamítnout či přijímout.

Git řeší pouze verzování. Služby jako GitHub řeší věci okolo, včetně např. issues.

Issues

  • možnost vytvářet tickety
  • jeden ticket představuje jednu věc:
    • chybu, error, bug
    • nápad, něco co chybí
    • informace o projektu
  • jednotlivé issues lze komentovat, uzavřít je či označit tagy

Projekty

  • zobrazuje listy věcí (případně issues)
  • často rozděleno na tři části:
    • To do
    • In progress
    • Done

Akce

  • dovolují nám napsat vlastní programy
  • dané programy můžeme přímo na GitHub volat
  • můžou se např. volat i při pushnutí do repozitáře
  • např. vybuildění Vue a nahrání na FTP server

Git dokumentace / knížka

https://git-scm.com/book/cs/v2

Jak na projekty

  • používejte větve
  • držte si dobrý managment toho, kdo co dělá (issues)
  • každý pull-request nechte někoho zkontrolovat
  • používejte projekty

Závěrečná práce

  • skupinový projekt
  • vytvoření interaktivní statické webové stránky
  • komunikace se zákazníkem na Discordu
    • nelze, že bude komunikovat jeden člověk (a to bude jeho celá práce)
  • vytvořený repozitář na GitHubu → odeslat jméno na GitHubu
  • kódovat musí všichni, zbytek si lze rozdělit jak chcete

Hodnocení

  • komunikace se zákazníkem
  • splnění požadavků zákazníka
  • využití gitu a GitHubu, komunikace v týmu
  • design, kód, použití technologií

Hodnotí se celá práce týmu, jako celek.

Práce musí být zcela legální, vše je nutné zdrojovat.

Každá skupina má různé zadání, které se může průběhu času měnit.

Každý skupina má jiného zákazníka, který bude reagovat různě, bude mít různé chování a požadavky.

Práce se bude po odevzdání prezentovat, kde se ukáže původní představa zákazníka, výsledek a celkově budete prezentovat, jak se Vám se zákazníkem komunikovalo, kdo za ním byl a podobně.

Práce se odevzdává kdykoliv, kdy bude zákazník spokojený. Nejdéle však do 1. 5. 2022.

TIPY:

  • nesnažte se kývnout na vše, co zákazník chce
  • se zákazníkem, i když například nebude odpovídat, komunikujte často, představujte mu své nápady
  • máte-li něco, co se musí rozhodnout, co nejvíce nechejte na zákazníkovi
  • pište formálně, srozutimitelně bez velkého množství technických termínů

Děkuji za pozornost!

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