webdev-js-evenings · mz10 · Jan 24, 2017 · Jan 24, 2017 · Jan 24, 2017 · Jan 24, 2017
diff --git a/README.md b/README.md
@@ -8,38 +8,39 @@ Kromě toho se dostaneme i k těm složitějším věcem, jako je například re
 a to i těch hluboko v historii.
 
 ## O nás
-Webdev / JS evenings klub byl založený Nikitou Mironovem. Nikita začínal učit Javascript a pak na něj navázal Honza Václavík a Dan Rys s jejich
-kurzem vývojem mobilních aplikací v Ionicu.
+Olomoucký Webdev vznikl za účelem sjednotit komunitu programátorů v Olomouci, pořádat pravidelné přednášky na zajímavá témata nebo 
+jen občas zajít posedět u piva.
 
-Teď jsem na řadě já Vojta Tranta ([@iVojta](https://twitter.com/ivojta)), JS vývojář v [Avocode](https://avocode.com/).
+Velký dík patří našemu sponzorovi [Reservio](https://www.reservio.com/cs/), díky kterému může být celá akce zdarma a
+bude k dispozici občerstevní ve formě kávy, piva, vody a snad i nějaké pizzy :) Děkujeme!
 
-Po mně následuje Petr a jeho kurz o automatizaci vývoje.
+Tento kurz bude z budu přednášet já [Daniel Suchý](https://danielsuchy.cz/), JS vývojář v [U+](https://u.plus/).
 
-Za to, že umím git vděčím hlavně chlapcům [@lukas_rychtecky](https://twitter.com/lukasrychtecky) a [@jankuca](https://twitter.com/jankuca)
+Za to, že umím GIT vděčím hlavně Vojtovi Trantovi [@iVojta](https://twitter.com/ivojta), který je také 
+původní autorem tohoto kurzu a materiálů, které budeme používat.
+
+Další velký dík patří také Nikitu Mironovi, který je zakladatelem pražského Webdev / JS evenings klub a který mě inspiroval pro založení
+toho našeho olomouckého.
 
 ## Začněte:
 1. [Git, Commit a branch](./commit-branch.md)
 2. [Git Flow](./git-flow.md)
 3. [Advanced Git](./advanced.md)
 
-## Díky
-Přišlo Vás opravdu hodně a my Vám za to děkujeme.
-
-Git workshop se tedy bude opakovat :)
-
-Video bude za ~týden.
-
-Následuje kurz automatizace vývoje.
-
-Díky
+## Užitečné zdroje a odkazy
+- [Git book - opensource kniha o gitu přeložená i do češtiny](https://git-scm.com/book/cs/v2)
+- [Autocomplete GIT příkazů](https://github.com/bobthecow/git-flow-completion/wiki/Install-Bash-git-completion)
+- [Zobrazení aktuální větve, počtu změněných souborů atd. přímo na řádce](https://github.com/magicmonty/bash-git-prompt)
 
-Vojta Tranta<br />
-[Webdev/JS Evenings](https://www.facebook.com/groups/webdevjs/?fref=ts)<br />
-[Avocode](https://avocode.com/)<br />
-[@iVojta](https://twitter.com/ivojta)<br />
-[vojta.tranta@gmail.com](vojta.tranta@gmail.com)<br />
+## Daniel Suchý
+[Webdev klub - OLOMOUC](https://www.facebook.com/groups/1874049622825379/) <br />
+[DanielSuchy.cz](https://danielsuchy.cz) <br />
+[suchydan@gmail.com](suchydan@gmail.com) <br />
 
 ## Credits
+- [Webdev klub - OLOMOUC](https://www.facebook.com/groups/1874049622825379/)
+- [Reservio](https://www.reservio.com/cs/)
+- [Vojta Tranta](https://twitter.com/ivojta)
+- [Daniel Suchý](https://danielsuchy.cz/)
 - [Nikita Mironov](https://www.facebook.com/why7e?fref=hovercard)
-- [Magda Tlučhořová](https://www.facebook.com/magdalena.tluchorova?fref=ts)
-- [Alza.cz](https://www.alza.cz/)
+- [Webdev/JS Evenings - PRAHA](https://www.facebook.com/groups/webdevjs/?fref=ts)<br />
diff --git a/commit-branch.md b/commit-branch.md
@@ -24,6 +24,26 @@
 ## K čemu to je dobrý?
 Představte si, že na projektu pracuje tisíc lidí. Co když mají všichni najednou otevřený jeden soubor? Nebo jsou všichni na jednom síťovém uložišti...?
 
+## Základní nastavení Gitu
+Po nainstalovaní gitu je potřeba provést základní nastavení. Nejdůležitější je nastavit vaše uživatelské jméno a email. Tyto údaje se budou používat při každem 
+vytvoření nového commitu.
+
+```
+$ git config --global user.name "Daniel Suchy"
+$ git config --global user.email suchydan@gmail.com
+```
+
+Pokud bychom chtěli nastavit jiné jméno nebo email pro konkretní projekt, spustíme tyto příkazy ve složce daného projektu, bez přepínače `--global`
+
+Pokud chceme předejít adrenalinovým zážitkům s VIMem, hodí se nastavit výchozí editor na něco více user friendly:
+```
+git config --global core.editor nano
+```
+Nebo stejný příkaz na Windows pro editor Notepad++:
+```
+git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -nosession"
+```
+
 ## Co je to Commit
 [![Commits](http://nvie.com/img/merge-without-ff@2x.png)](Commits)
 
@@ -75,7 +95,7 @@ Tady máte schémátko, jak vypadá commity, když jdou za sebou...
 
 **Forkneme** si **repozitář** (repozitář je složka na serveru nebo lokálně, ve které je Git inicializovaný - prostě tam, kde se daj dělat Git příkazy).
 
-https://github.com/js-evenings/git-workshop
+https://github.com/Nodonisko/git-workshop
 
 **Forknutí** znamená, že si repozitář zkopírujeme ke svému účtu na Githubu (GitLabu, Bitbucketu...), přičemž si naše kopie pamatuje svého původního bratra, ale chová se jako samostatný adresář, který bychom si sami vytvořili.
 
@@ -101,7 +121,8 @@ Pokud znova spustíme `git status` měla by se zobrazit změny `new file: notes.
 
 Tato změna bude **unstaged**. Unstaged změny jsou takové, které nejsou připravené ke commitnutí.
 
-Krom toho bude soubor `notes.md` v terminologii Gitu brán jako **untracked**. Untracked soubor je takový soubor, který ještě nikdy nebyl přidán do Gitu. Tudíž Git sice vidí, že tam takový soubor je, ale nesleduje zatím jeho změny.
+Krom toho bude soubor `notes.md` v terminologii Gitu brán jako **untracked**. Untracked soubor je takový soubor, který ještě nikdy nebyl přidán do Gitu.
+Tudíž Git sice vidí, že tam takový soubor je, ale nesleduje zatím jeho změny.
 
 V tomhle případě je změnou vytvoření nového souboru. Git dokáže jednoduše rušit unstaged změny přes příkaz `git checkout`, ale to nefunguje na přidání složek nebo souborů, ty se normálně mažou pomocí `rm`.
 ```
@@ -127,6 +148,8 @@ $ git config --global alias.s 'status'
 $ git config --get-regexp alias
 ```
 
+### Zpět ke commitu
+
 Vytvoříme znovu soubor `notes.md` a pak přes `git s` uvidíme, že soubor byl znovu objeven Gitem!
 
 Unstaged změny nejdou commitnout:
@@ -135,7 +158,8 @@ Unstaged změny nejdou commitnout:
 $ git commit -m "tohle je přidání souboru" // nic se nestane
 ```
 
-Prve je potřeba si změny, se kterýma počítáme do commitu, - to jsou ty hezké učesané, odložit do **stage** fáze před commit, prostě si je tam hezky připravujeme. Staged změny jsou ty, které budou commitnuty, jakmile napíšeme příkaz `git commit`. Přidání do stage se dělá pomocí příkazu:
+Prve je potřeba si změny, se kterýma počítáme do commitu, - to jsou ty hezké učesané, odložit do **stage** fáze před commit, prostě si je tam hezky připravujeme. 
+Staged změny jsou ty, které budou commitnuty, jakmile napíšeme příkaz `git commit`. Přidání do stage se dělá pomocí příkazu:
 
 ```
 // přidání do stage pro commit - příprava pro commit, uschování změn
@@ -175,11 +199,12 @@ $ rm notes.md
 No tak to už umíme, tak si pojďme ten soubor commitnout příkazem:
 
 ```
+// převedeme všechny soubory do stavu staged tzn. stavu kdy jsou připraveny ke commitnutí
 $ git add --all
 
 $ git commit
 ```
-**GOTCHA:** defaultní editor pro úpravu commit messages a vůbec všeho textového v Gitu je VIM.
+**GOTCHA:** Pokud jste si defaultní editor nezměnili pomocí git.config, je pro úpravu commit messages a vůbec všeho textového v Gitu VIM.
 A nikdo neví, jak do něj něco napsat nebo hůř, jak se z něj dostat, proto:
 
 Přepneme do zapisovacího módu:
@@ -207,7 +232,7 @@ Pokud chceme předejít adrenalinovým zážitkům s VIMem, hodí se nastavit v
 git config --global core.editor nano
 ```
 
-Jasně, nikoho nebaví se furt přepínat do VIMu. Proto existuje zkratka, kterou používám:
+Jasně, nikoho nebaví se furt přepínat do VIMu. Proto existuje zkratka, díky které nemusí lézt do žádného editoru:
 ```
 $ git commit -m "commit messsage"
 ```
@@ -245,7 +270,7 @@ $ git log
 // hezčí zobrazí seznamu
 $ git log --pretty=oneline -n 50 --graph --abbrev-commit
 // uděláme na něj alias
-$ git config --globa alias.l 'log --pretty=oneline --graph --abbrev-commit --branches --decorate -n 100'
+$ git config --global alias.l 'log --pretty=oneline --graph --abbrev-commit --branches --decorate -n 100'
 //vyzkoušíme
 $ git l
 
@@ -260,7 +285,7 @@ Nejjednoduší "smazání" je přes příkaz **reset**:
 // smazání posledního commitu (nejaktuálnějšího)
 $ git reset --hard HEAD~1 // odeber jeden nejnovější commit (na dané větvi)
 // případně
-// $ git rest --hard HEAD~2 // odeber dva nejnovější commity (na dané větvi)
+// $ git reset --hard HEAD~2 // odeber dva nejnovější commity (na dané větvi)
 ```
 **HEAD**? Řikáte si, co je to HEAD? Head je označení pro poslední commit větve nebo prostě commit, na kterém jste nastaveni. Proto mám poznamenáno:
 
@@ -270,7 +295,7 @@ Nyní se podíváme na stav commitů, jak jdou za sebou `git l`. Vidíme, že n
 
 **GOTCHA:** Smazat něco v Gitu je těžká práce, fakt hodně těžká. Smazat commit je z toho asi nejtěžší. Git po nějaké době maže sám ty commity, které nejsou u žádné branche (vysvětlíme). Chová se jako garbage collector a prostě maže to, k čemu není přístup.
 
-Takže Vojto, ten commit je smazaný? Ne, není. Jenom jsme ho odebrali z větve, snadno ho dáme zpátky. Je spousta cest, jak to udělat.
+Takže je ten commit opravdu smazaný? Ne, není. Jenom jsme ho odebrali z větve, snadno ho dáme zpátky. Je spousta cest, jak to udělat.
 
 #### Cherry-pick
 V našem případě si můžeme krásně zkusit příkaz **cherry-pick** (cherry-pick prostě vezme odněkud commit a přidá vám ho pod ruku (na vrchol branch a posune tak ukazatel HEAD), jak kdybyste ho právě udělali ručně):
@@ -288,12 +313,16 @@ Takže umíme:
 - přidat změnu do stage pro commit
 - smazat změnu ze stage pro commmit
 - vytvořit commit
-- jít do insert modu ve VIMu
-- odejít z VIMu
 - smazat poslední commity z branche
 - cherry-picknout commit zpátky
 
 Procvičit! Celé znovu!!
+```
+$ cd ..
+$ rm -rf git-workshop
+// znova!
+```
+
 **Úkoly**: Vše kontrolovat přes `git s` nebo `git l`!!!
 - vytvořit soubor `cvicime.md`
 - přidat soubor do stage pro commit
@@ -310,11 +339,6 @@ Procvičit! Celé znovu!!
 - smazat oba dva commity najednou
 - dostat přes Git je zpátky
 
-```
-$ cd ..
-$ rm -rf git-workshop
-// znova!
-```
 
 ### Pokročilé operace
 
@@ -332,7 +356,9 @@ Teď si každej řekne "Do piči, ten soubor `ten-se-ma-jmenovat-jinak.js` se m
 
 Jak to smáznout z commitu? Mno.
 
-Jak jsem pravil, commit je neměnitelný - (immutable), tudíž commit jako takový nejde změnit, jde pouze nahradit jiným - snad nekecám. To je nám ale celkem šumák, protože výsledek je stejný. Kolikrát to ani člověk nepozná, neboť se u commitu třeba jenom změnit `commit id`.
+Jak jsem pravil, commit je neměnitelný - (immutable), tudíž commit jako takový nejde změnit, jde pouze nahradit jiným - snad nekecám. 
+To je nám ale celkem šumák, protože výsledek je stejný. 
+Kolikrát to ani člověk nepozná, neboť se u commitu třeba jenom změnit `commit id`.
 
 Takže **amend**:
 ```
@@ -514,6 +540,20 @@ Jde o to, že když jsme vytvářeli branch `english` tak ona se vytvoří z bod
 
 Proto je třeba nějak říct větvi `english`, aby se aktualizovala a my mohli překládat dál, jak to uděláme?
 
+### Merge
+Merge vezme branch, kterou mergujete do aktulní branche. Pak ji "schová" do `merge commitu` a pokud se vyskytnout konflikty, tak vám poručí je vyřešit a pak změny commitnout a tím se vytvoří merge commmit.
+
+#### Merge Commit
+Je zvlášní druh commitu, který drží ukazele na commity z branche, kterou mergujete. Takže je to commit, který v sobě schovává víc commitů. Výsledek merge je stejný jako výsledek rebasu - máte spojené dvě větve v jednu - s tim rozdílem, že merge vytvoří explicitní merge commit, kde jsou vyřešené konflikty, zatímco pomocí rebasu jen měníte stávající commity tak, aby nekonfliktovali.
+
+`Merge commit` se dá snadno smazat normálně pomocí `git reset --hard`.
+
+Takže namergujeme vetěv master do naší větve `english` pomocí příkazu:
+
+```
+$ git merge master
+```
+
 ### Rebase
 Rebase je asi nejmocnější nástroj v Gitu, co existuje. Jdou s ním dělat neskutečný věci, ale prozatím stačí, když ho použijeme na aktualizaci větve `english` tak, aby její první commit měl za předka poslední, aktuální commit na větvi `master`. Prostě jí `pře-bázujeme`.
 
@@ -548,4 +588,61 @@ Je zvlášní druh commitu, který drží ukazele na commity z branche, kterou m
 
 V Master a Dev branchích jsou vidět merge commity, aby bylo jasné, jaké branch se kdy udělala a kdo jí udělal.
 
+## Ad.1 Branching - příklad přímo ze života programátora
+
+Je super že už umíme používat branche, mergovat a rebasovat, ale jak to použijeme při programování?
+
+Typický příklad že života je např. práce na webových stránkách. Pracujete na nějaké nové funkci na úvodní straně, v tom vám
+přijde mail že je potřeba rychle něco hotfixnout nebo upravit taktéž na domovské straně, nebo kdekoliv jinde.
+
+Jak to teda uděláte když nemáte GIT? Máte několik možností, můžete soubor upravit přímo na FTP serveru na produkci, nebo jsi z FTP můžete stáhnout do další
+složky původní verzi projektu, tam ji upravíte, otestujete a nahrajete zase zpátky. Pak také nesmíte zapomenout fix překopírovat do verze projektu kde máte rozpracovanou
+novou funkčnost. No prostě prostě prasárna vedle prasárny.
+
+Ale pokud máte GIT, použijete elegatní způsob pomocí branchí.
+
+#### Vytvoření vývojové větve
+```
+// vytvoření větve feature a přepnutí do ní rovnou
+$ git checkout -b feature
+```
+
+Nyní začneme pracovat na nové fičuře, doděláme jen část a najednou nám přichází email nebo telefonát že je nutně potřeba něco opravit. Tak jednoduše commitneme to co máme:
+
+```
+$ git add --all
+$ git cm "new menu"
+```
+
+Zatím ještě nechceme naše změny propisovat na web, protože ještě nejsou dokončeny a otestovány. Tak jak na to?
+
+Přepneme do masteru, pomocí `git checkout`. Poté provede požadovanou opravu a commitneme.
+
+```
+$ git checkout master
+$ git add --all
+$ git cm "footer email change"
+```
+
+Nyní můžeme beze strachu nahrát náš master na FTP a pak se pomocí `git checkout` přepnout zpátky na naši feature větev a pokračovat v práci.
+
+Jakmile dokončíme práci, můžeme pomocí `git commit --amend` připojit práci k předchozímu commitu s nedokončenou prací abychom nevytvářeli polovičaté commity.
+
+```
+$ git checkout feature
+$ git add --all
+$ git commit --amend
+```
+
+Co když ale budeme potřebovat fix, nebo úpravu co jsme udělali na masteru otestovat i s naší novou feature? Použijeme `git rebase`:
+
+```
+$ git rebase master
+```
+
+A máme hotovo, máme vytvořenou novou feature i s posledním fixem z masteru. Pokud by něco nefungovalo jednoduše to opravíme a commitneme. Jakmile máme vše otestováno, můžeme naši feature branch mergnout do masteru:
+```
+$ git checkout master
+$ git merge feature
+```