Git

DVOP WBB


Bc. Matěj Cajthaml — SSPŠ

©

Verzovací systémy

Verzovací systém

  • = version control
  • správa změn projektu
  • revize
  • často i v jednotlivých službách

Na jaké typy projektů používáme verzovací systémy?

Proč bychom potřebovali verzovat projekt?

Je např. klasické kopírování složek verzovací systém?

Způsoby práce ve verzovacích systémech

Zamykání souborů

  • soubor / projekt
  • pouze jeden člověk může pracovat
  • ochrana proti zásahu ostatních

Spojování změn

  • může pracovat více lidí najednou
  • změny se poté spojí
  • problémy se spojením — změny ve stejném místě
  • tzv. merge-conflict (příští hodiny)

Na jaké typy projektů se hodí zamykání souborů a spojování změn?

Umístění verzování

  • centralizované (centralized)
  • decentralizované (decentralized)
  • distribuované (distributed)

  • komunikace se serverem jen, když je potřeba

Historie verzí

  • lineární — každá verze závisí na předchozí
  • grafový — orientovaný acyklický graf, kde z jedné verze může existovat více verzí, které se mohou spojit

Známé verzovací systémy

  • Git
  • Subversion
  • CVS
  • Bazaar

Git

Git

  • verzovací systém
  • opensource
  • velmi populární
  • vytvořeno v roce 2005, Linus Torvalds, Junio Hamano
  • HTTP, FTP, SSH, ...

Cíle Gitu

  • být jednoduchý
  • podporovat distribuované použití
  • být zdarma
  • být rychlý
  • ochránit proti ztrátě dat

Charakteristiky

  • data se po odeslání jen tak neztratí
  • jednotlivé změny jsou závislé na celém repozitáři
  • každý objekt v Gitu je označen jednoznačným identifikátorem pomoci SHA-1
  • různé OS, systémy a jazyky
  • Git při většině akcí nekomunikuje se sítí a proto rychlost závisí jen na HW

Git neukládá změny, ale jejich snímky. Pokud se v dané verzi nezměnil, je uložen odkaz na jeho předchozí verzi.

Časti Gitu

  • working directory — pracovní adresář
  • staging area — připravené změny
  • Git directory — složka pro Git

Pro jakoukoliv práci s Gitem je potřeba mít nainstalovaný Git v příkazové řádce (CLI). Git je pro jednoduchost podporován i s grafickým designem (GUI) — ty prozatím používat nebudeme.

Instalace

  • Git-scm
  • po instalaci je nutné nastavit Vaše jméno a e-mail
  • pro vše se používá příkaz git, který má podpříkazy

Nastavení osobních informací

Zobrazení nastavení

Nápověda

Cílem této a následující hodiny není, abyste si zapamatovali všech ~150 příkazů, ale abyste uměli používat každý den základní sadu cca 30 příkazů.

Repozitář

Repozitář

  • samotný projekt
  • musíme vytvořit nebo klonovat z internetu
  • sleduje veškeré změny projektu od počátku

Vytvoření repozitáře

  • v aktuální složce založí repozitář
  • mohou existovat již soubory / projekt
  • vytvoří složku .git

Ve složce .git se nachází veškeré verze souborů (tj. snímky) a informace o repozitáře. Smazáním této složky přijdete o lokální kopii verzí.

Commit

Commit

  • jedná se o balíček změn
  • zaznamenané, ukončené (a připravené k odeslání)

Stav souborů

  • untracked — nesledované, nový soubor
  • unmodified — sledovaný soubor, který se ale ve verzi nezměnil
  • modified — sledovaný soubor, který se od poslední revize změnil
  • staged — sledovaný soubor, který je připraven ke commitu

Zjištění stavu souborů

  • zobrazuje status všech souborů projektu bez unmodified

Zjištění stavu souborů

  • označí daný soubor jako staged

Staged!

Práce

1. V repozitáři si vytvořte soubor test.txt a vložte do něj své křestní jméno. Daný soubor označte jako staged. Co se nachází ve výstupu příkazu git status?

2. Upravte soubor test.txt aby obsahoval na více i Vaše příjmení. Co se nachází ve výstupu příkazu git status?

Při označení souboru jako staged pomocí git add <soubor> se označí daný stav souboru a ne soubor samotný. Jeho změny v budoucnu již nebudou jako to-be-commited označeny.

Jak uděláme, aby i další změny byly zaznamenané a označené jako staged?

Vidíte v příkazu git status nějaký problém?

Kompletní zobrazení změn

  • zobrazí změny dle jednotlivých řádek
  • formát tzv. patch
  • přepínač --staged

Zapsání změn

Zapsání změn

  • (to) commit
  • zapsání staged souborů jako revizi
  • každý commit má:
    • jméno (a případně popis)
    • časovou značku
    • identifikátor dle SHA-1
    • kdo jej vytvořil

Commit

  • bez uvedení názvu se otevře editor, kde jméno lze zadat
  • jak se správně mají commity jmenovat si řekneme příště

Po commitu se vyčistí staged soubory a cyklus může pokračovat.

Ukázka repozitáře

                        gitGraph
                            commit id: "Initial commit"
                            commit id: "Add test.txt"
                            commit id: "Add test2.txt"
                            commit id: "feat: test.txt - add my name"

Smazání a přesouvání souborů

Práce

Umí Git zaznamenat přesunutí souboru?

Jak v Gitu smažeme soubor?

Pokročilá práce s Gitem

Přidávání více souborů najednou

  • -A — označí vše
  • . — označí vše v aktuální složce (rekurzivně)
  • -u — označí modifikace a smazání, bez nových souborů

Speciální soubory gitu

.gitignore

  • všechny soubory, které splňují pravidla nebudou přidávany a sledovány

Historie verzí

Historie verzí

  • často potřebujeme zobrazit, co se v repozitáři stalo
  • tento příkaz nám dovolí zobrazit commity, na které můžeme v dalších příkazech referovat
  • spousta přepínačů
  • záznam je chronologický (první záznam je poslední commit)

Historie verzí

Návrat do předchozího stavu

Připojení k minulému commitu

  • v posledním commitu chcete něco opravit
  • to, co je označené jako staged se vezme a přidá k minulému commitu
  • otevře se editor k opravě jména / lze zadat pomocí -m
  • nevytváří se nový commit

Co po amend?

Co se stane, když provedeme změny a amend?

                        gitGraph
                            commit id: "..."
                            commit id: "... "
                            commit id: "...  "
                            commit id: "...   "
                            commit id: "...    "
                            commit id: "...     "
                            commit id: "feat: way to add unlimited pointz"

Odstranění označení staged

  • soubor, který do aktuálních změn nechceme zahrnout
  • nemaže změny

Resetování aktuálně změněného souboru

  • resetuje soubor do poslední revize daného souboru
  • aktuální stav bude nenávratně smazán

Vzdálené repozitáře

Práce se vzdálenými repozitáři

  • Git využíváme skoro vždy pro práci v týmech
  • kopírování složky Gitu je špatné a náročné
  • do repozitáře si můžeme nalinkovat různé cizí repozitáře s internetem a s nimi komunikovat
  • vzdálené repozitáře můžeme přejmenovávat i smazat

Vzdálené repozitáře existují v odděleném prostředí. Změnami ve working directory je nemůžeme ovlivnit.

Získání kódu ze vzdáleného repozitáře

  • NEOVLIVŇUJE lokální repozitář či working directory, jen se stáhnou

Klonování repozitáře

  • místo založení lokálního repozitáře si můžeme naklonovat repozitář z internetu
  • automatické spojení
  • můžeme nahrávat změny
  • HTTPS / SSH

Git vs. Gitové služby

  • Git je verzovací nástroj
  • GitHub, GitLab a další jsou služby, které Git uvnitř používají
  • tyto služby nabízejí hostování repozitáře a další nástroje

Vzdálený repozitář

                        gitGraph
                            branch origin/master
                            checkout main
                            commit id: "..."
                            commit id: "... "
                            commit id: "...  "
                            commit id: "...   "
                            checkout origin/master
                            commit id: "...      "
                            checkout main
                            commit id: "...    "
                            commit id: "...     "
                            checkout origin/master
                            commit id: "...       "

Větve

Jak se na sebe vážou commity?

Větve

  • oddělení od hlavního vývoje (vlastní prostředí)
  • neovlivňujeme ostatní větve (např. produkci)
  • větve UKAZUJE na nějaký commit (serii snímků), který označuje posledni jeho stav

Větev, která se vytvoří na začátku (main / master) nemá žádné speciální funkčnosti.

Větve

                        gitGraph
                            branch dev
                            checkout main
                            commit id: "..."
                            commit id: "... "
                            commit id: "...  "
                            commit id: "...   "
                            checkout dev
                            commit id: "...      "
                            merge main
                            checkout main
                            commit id: "...    "
                            commit id: "...     "
                            checkout dev
                            commit id: "...       "
                            checkout main
                            merge dev

Vytvoření větve

  • založí novou větev ale nepřepne do ni
  • jedná se o LOKÁLNÍ větvi
  • větev můžeme kdykoliv smazat pomocí přepínače -d / -D

Přepnutí do jiné větve

  • přepne do nové větve, ve které budeme dělat změny
  • musíme resetovat soubory (i staged)
  • resetuje soubory do daného posledního commitu v dané větvi

Co se stane, když přepneme do nové větve, když máme nějaké rozpracované soubory?

Jak Git ví, v jaké větvi se aktuálně nacházíte?

Značka HEAD

  • odkazuje na aktuální větev
  • uvnitř git log můžeme vidět odkazy na HEAD a větve

Při vytvoření commitu ve větvi se rozdělí (rozběhne) historie. Pomocí git log --graph --all zobrazíme celý seznam.

Ukázka práce v repozitáři

  1. Založit repozitář pro imaginární stránku.
  2. Vytvoříme základní strukturu.
  3. Pro novou změnu (přidání kontaktu) vytvoříme novou větev a začneme na ni pracovat.
  4. Přidáme část kontaktu a commitneme.
  5. Mezitím se nám dostala informace o okamžitém opravení hlavní verze (typo / legal issues).
  6. Vrátíme se do hlavní větve, vytvoříme novou větev, chybu opravíme a commitneme.
  7. Spojíme novu větev s hlavní větví.

Kolik větví může repoziář mít?

Slučování větví

Slučování větví

  • proces, kdy změny v jedné větvi spojíme do druhé
  • spojujeme zadanou větev do AKTUÁLNÍ VĚTVE

Slučování může být jednoduché (jen se posune ukazatel větve) a nebo složitější, které vytváří speciální commit.

Merge conflict

  • = konflikt při slučování
  • nastane, když v různých revizí změníte stejnou část souboru a Git neví, co udělat
  • musí se vyřešit ručně (nebo pomoci GUI)

Všechny nevyřešené merge conflicty lze vidět pomocí git status. Až soubory opravíte, můžete se slučováním pokračovat pomocí git commit.

Zobrazení větví

Vzdálené větve

  • název <jméno vzdáleného repozitáře>/*
  • lze je smazat
  • pokud na vzdáleném repozitáři lokální neexistuje, musíme ji při git push vytvořit

Nahrání změn

  • na vzdálený repozitář (větev) potřebujeme odeslat změny
  • před odesláním musíme změny získat (implementovat) pomocí git fetch

Získání změn a jejich začlenění

  • git fetch změny jen stáhne
  • tento příkaz je stáhne a implementuje do pracovního adresáře
  • reálně se jedná o příkazy git fetch a git merge

Jak vypadá stažení změn?

                        gitGraph
                            branch origin/main
                            commit id: "1-1a3bee1"
                            checkout main
                            commit id: "1-1a3bee1"
                            commit
                            commit
                            commit
                            checkout origin/main
                            merge main
                            commit
                            commit
                            commit
                            checkout main
                            merge origin/main

Git je verzovací nástroj, který nám dovoluje hlídat verze. Jak se můžeme vrátit k nějaké revizi?

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), cherry-pick, squash, ...
  • 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.

Děkuji za pozornost!

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