Slovníček

Obsah

• Úvod
• Jak to funguje
• Autentizace na GitHub pomocí SSH
• Vytvoření a stáhnutí projektu
• Základní příkazy
• Verzovací strategie
  • GitFlow
  • GitHub flow
• Odkazy

Úvod

Pokud vyvíjíme software, potřebujeme kód sdílet s ostatními vývojáři, ale také se nám hodí sledovat kdo a kdy provedl jakou změnu. Pryč jsou doby, kdy se zdrojové kódy předávaly na disketách a discích (jako například při vývoji DOOMu, kdy se to řešilo tak, že každý vývojář pracoval na vybraných funkcionalitách sám a mohl je tak nahrávat ostatním :-)

Jak to funguje

Git je nástroj, který sleduje změny v souborech a každý vývojář, který se na projektu podílí má k dispozici celý projekt se zdrojovými soubory. Vývojář může vyvíjet offline a zároveň jednotlivé kopie slouží jako zálohy, pokud by selhalo centrální úložiště. Každý vývojář si ukládá svoje změny (commit) do lokálního repositáře (lokální evidence změn), které může odeslat (push) do centrálního repositáře. Existence centrálního úložiště (například GitHub) je volitelná. Aktuální stav projektu je možné zase z centrálního úložiště stáhnout (pull) do lokálního. Kód je možné ukládat a verzovat do různých větví (branches), což nám umožňuje neomezené množství workflow strategií (branching strategies).

Git disponuje takzvanou staging areou, což jsou námi označené změny, které chceme commitnout (uložit do lokálního repositáře)

Základní workflow, jakým verzování funguje, vypadá následovně

Autentizace na GitHub pomocí SSH

Git je možné používat v offline režimu pouze na našem počítači, ale pokud budeme chtít synchronizovat s platformou GitHub, máme k dispozici SSH autentizaci. SSH klíče si vygenerujeme následujícím způsobem z příkazové řádky

> ssh-keygen -t rsa -b 4096 -C "vas_email@domain.tld"
> ssh-add ~/.ssh/id_rsa

• ssh-keygen nám vygeneruje veřejný a privátní klíč.
• ssh-add nám privátní klíč zaregistruje u SSH agenta. Díky tomu klíč budeme moci později použít pro autentizaci.

Poté se přihlásíme do svého GitHub účtu a vygenerovaný veřejný klíč id_rsa.pub nahrajeme do svého profilu následujícím postupem:

> ssh -T git@github.com
> Hi Ninjanaut! You've successfully authenticated, but GitHub does not provide shell access.

Vytvoření a stáhnutí projektu

Na hlavní stránce vytvoříme nový projekt (repository), vybereme jestli chceme privátní nebo veřejný repositář, zvolíme licenci a také můžeme nastavit .gitignore soubor z předem definovaných šablon (šablona určuje, které soubory nebo typy souborů nechceme do repositáře nahrávat).

> cd "C:\workspace"
> git clone git@github.com:Ninjanaut/testproject.git

> cd testproject
> code .

Základní příkazy

Všechny příkazy budeme zadávat do příkazové řádky nebo Git Bashe, ale je možné použít i GUI klienta, například Git GUI, GitHub Desktop, Visual Studio Code, GitKraken, apod.

# Přepneme se do složky, ve které budeme chtít mít projekt uložený
> cd "C:\workspace"

# Zkopírování projektu (repositáře) z GitHub
> git clone git@github.com:ucet/jmeno_projektu.git

# Přepnutí se do projektu
> cd jmeno_projektu

# Přidání všech změn do STAGE oblasti.
# Stage oblast obsahuje všechny změny, které ještě nebyli commitnuté, ale evidujeme je jako součást následujícího commitu.
> git add .

# Lokální commit všech změn
> git commit -m "Add readme.md and LICENSE"

# Zkratka pro předchozí dva příkazy
> git commit -am "Add readme.md and LICENSE"

# Zobrazení historie commitů
> git log

# Zobrazení aktuálního stavu repositáře.
# Fetch stáhne informace o změnách na serveru.
# Status zobrazí rozdíly mezi lokálním a hlavním repositářem.
> git fetch
> git status

# Stáhnutí změn ze serveru do lokálního projektu
> git pull

> git push

> git checkout develop

Verzovací strategie

Při práci s verzovacím nástrojem si vždy musíme určit způsob práce a pravidla (workflow), kterými se budeme řídit. GitFlow a GitHub Flow jsou asi nejznámější strategie, které je možné upravit dle potřeb.

GitFlow

GitFlow je robustní verzovací strategie, která pracuje s pěti větvema. master a develop jsou hlavní větve. feature, release a hotfix jsou speciální větve, které mají omezenou životnost.

Master branch

Hlavní větěv, která je vždy v "production-ready" stavu. Každý commit do ní znamená nový release.

Develop branch

Vývojová větěv, do které se zapracovávají nové funkcionality a změny, které chceme mít v dalším releasu. V momentě kdy je větev stabilní, můžeme z ní vytvořit release větev.

Feature branch

• Slouží pro vývoj nových funkcionalit a existuje tak dlouho, jak dlouho vyvíjíme funkcionalitu. Jakého releasu bude daná funkcionalita součástí nemusíme v danou chvíli vědět.
• Jméno je libovolné, kromě master, develop, release-*, hotfix-*.
• Musí mergovat z develop do develop.

# vytvořit a přepnout se do nové větve "myfeature"
> git checkout -b myfeature develop

# Až bude funkce hotová, přepneme se zpátky do develop větve
> git checkout develop

# Mergneme feature větev
> git merge --no-ff myfeature

# Smažeme feature větev
> git branch -d myfeature

# Nahrajeme na centrální repositář
> git push origin develop

Release branch

• Slouží pro přípravu produkčního releasu. Tím se uvolní development větev pro další funkce.
• Konvence pro jméno je release-*.
• Musí mergovat z develop do develop a master.

# Vytvoří a přepne se do nové větve "release-1.2"
> git checkout -b release-1.2 develop

# případné úpravy související s releasem a commitneme je, může se jednat i o bugfixy v rámci testu.
> git commit -a -m "Bumped version number to 1.2"

# Přepnutí se do master větve, merge (real release) a otagujeme.
> git checkout master
> git merge --no-ff release-1.2
> git tag -a 1.2

# Přepnutí se do develop větve a merge
> git checkout develop
> git merge --no-ff release-1.2

# Smažeme release větev, kterou již nepotřebujeme
> git branch -d release-1.2

Hotfix branch

• Jedná se o neplánovaný a okamžitý release, který má za úkol fixnout kritickou chybu, která nepočká do standardního releasu.
• Konvence pro jméno je hotfix-*.
• Musí mergovat z master do develop a master.

# Vytvoří a přepne se do nové větve "hotfix-1.2.1"
> git checkout -b hotfix-1.2.1 master

# Přípradné změny ve version číslování a opravení chyby
> git commit -a -m "Bumped version number to 1.2.1"
> git commit -m "Fixed severe production problem"

# Přepneme se do master větve, mergneme a otagujeme
> git checkout master
> git merge --no-ff hotfix-1.2.1
> git tag -a 1.2.1

# Přepneme se do develop větve a mergneme, (výjimečně můžene i do release větve, pokud existuje).
> git checkout develop
> git merge --no-ff hotfix-1.2.1

# Smažeme již nepotřebnou hotfix větev
> git branch -d hotfix-1.2.1

GitHub Flow

GitHub Flow je odlehčené a méně zformalizované workflow. Máme zde k dispozici hlavní main větev, která je vždy v "production-ready" stavu, je tedy stejná jako master větev v GitFlow. Dále pro novou funkcionalitu nebo hotfix také vytváříme novou větev a do testovacího nebo produkčního prostředí nasazujeme již z těchto větví a až potom co se větev odzkouší, tak teprve v ten moment jí mergujeme do main větve.

Odkazy

• Historie Gitu
• GitFlow originální článek
• GitHub flow
• Připojení ke GitHub pomocí SSH