From 03ad1c649458a29f98cb1b8d92c7f34a6e22ab3a Mon Sep 17 00:00:00 2001
From: Daniel Suchy <suchydan@gmail.com>
Date: Tue, 24 Jan 2017 13:53:45 +0100
Subject: [PATCH 1/9] Delete unused files

---
 git-flow/good-music.md                 | 2 --
 git-flow/ucastnici/6.8.2016/luciest.md | 4 ----
 ucastnici/6.8.2016/Ivorius.md          | 1 -
 ucastnici/6.8.2016/TomasNyvlt.md       | 4 ----
 ucastnici/6.8.2016/bohdanpartyk.md     | 1 -
 ucastnici/6.8.2016/codeas.md           | 3 ---
 ucastnici/6.8.2016/jvaclavik.md        | 1 -
 ucastnici/6.8.2016/nodonisko.md        | 1 -
 ucastnici/6.8.2016/petr_kysela.md      | 3 ---
 ucastnici/6.8.2016/petrhamacek.md      | 2 --
 ucastnici/6.8.2016/qeef.md             | 1 -
 ucastnici/6.8.2016/snizemic.md         | 1 -
 ucastnici/6.8.2016/strakator.md        | 1 -
 ucastnici/6.8.2016/vahyThe.md          | 1 -
 ucastnici/6.8.2016/vojtatranta.md      | 1 -
 15 files changed, 27 deletions(-)
 delete mode 100644 git-flow/good-music.md
 delete mode 100644 git-flow/ucastnici/6.8.2016/luciest.md
 delete mode 100644 ucastnici/6.8.2016/Ivorius.md
 delete mode 100644 ucastnici/6.8.2016/TomasNyvlt.md
 delete mode 100644 ucastnici/6.8.2016/bohdanpartyk.md
 delete mode 100644 ucastnici/6.8.2016/codeas.md
 delete mode 100644 ucastnici/6.8.2016/jvaclavik.md
 delete mode 100644 ucastnici/6.8.2016/nodonisko.md
 delete mode 100644 ucastnici/6.8.2016/petr_kysela.md
 delete mode 100644 ucastnici/6.8.2016/petrhamacek.md
 delete mode 100644 ucastnici/6.8.2016/qeef.md
 delete mode 100644 ucastnici/6.8.2016/snizemic.md
 delete mode 100644 ucastnici/6.8.2016/strakator.md
 delete mode 100644 ucastnici/6.8.2016/vahyThe.md
 delete mode 100644 ucastnici/6.8.2016/vojtatranta.md

diff --git a/git-flow/good-music.md b/git-flow/good-music.md
deleted file mode 100644
index 272e3f6..0000000
--- a/git-flow/good-music.md
+++ /dev/null
@@ -1,2 +0,0 @@
-Vláček: https://youtu.be/atyvdC15HFA
-Tommy Emmanuel https://www.youtube.com/watch?v=6lbvSBNLLoo
diff --git a/git-flow/ucastnici/6.8.2016/luciest.md b/git-flow/ucastnici/6.8.2016/luciest.md
deleted file mode 100644
index fd6ec77..0000000
--- a/git-flow/ucastnici/6.8.2016/luciest.md
+++ /dev/null
@@ -1,4 +0,0 @@
-# Opravené hodnocení
-Nejvíc nejlepší a nejlovískovatější kurz.
-A srdíčko k tomu, samozřejmě. <3
-**A žádný prázdný řádky!!!**
diff --git a/ucastnici/6.8.2016/Ivorius.md b/ucastnici/6.8.2016/Ivorius.md
deleted file mode 100644
index b63564a..0000000
--- a/ucastnici/6.8.2016/Ivorius.md
+++ /dev/null
@@ -1 +0,0 @@
-Zkou��m �kolen� p�es net. Zat�m dobr�, jen p�r chybek v nastaven� git config --global
\ No newline at end of file
diff --git a/ucastnici/6.8.2016/TomasNyvlt.md b/ucastnici/6.8.2016/TomasNyvlt.md
deleted file mode 100644
index 415fa09..0000000
--- a/ucastnici/6.8.2016/TomasNyvlt.md
+++ /dev/null
@@ -1,4 +0,0 @@
-Issue5
-
-
-Je to super!
diff --git a/ucastnici/6.8.2016/bohdanpartyk.md b/ucastnici/6.8.2016/bohdanpartyk.md
deleted file mode 100644
index b48ec0b..0000000
--- a/ucastnici/6.8.2016/bohdanpartyk.md
+++ /dev/null
@@ -1 +0,0 @@
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vivamus volutpat lorem vel sem lacinia hendrerit. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Maecenas libero arcu, fermentum sollicitudin imperdiet sed, accumsan sit amet libero. Mauris sed mattis tellus, vel pretium mi. Phasellus laoreet dolor eu nulla congue, sollicitudin commodo justo consequat. Cras fringilla egestas arcu, ut commodo leo aliquet ut. Nam magna justo, suscipit id consectetur nec, porttitor vel lectus. Nam sit amet placerat libero. Quisque vitae lectus et odio gravida ullamcorper. Pellentesque tincidunt gravida massa, sed auctor lacus posuere non. Donec laoreet efficitur dui, ac efficitur leo iaculis a. Nam nec eros non neque blandit cursus sit amet at diam. Nulla at mauris est. Phasellus ac pellentesque magna. Nullam bibendum aliquam lacus, quis lacinia nunc tempus sed. Vestibulum maximus posuere nisl, ut condimentum nibh eleifend faucibus.
diff --git a/ucastnici/6.8.2016/codeas.md b/ucastnici/6.8.2016/codeas.md
deleted file mode 100644
index 28d71cb..0000000
--- a/ucastnici/6.8.2016/codeas.md
+++ /dev/null
@@ -1,3 +0,0 @@
-A středa je malý čtvrtek,
-A úterý je malá středa
-A pondělí je malé úterý
\ No newline at end of file
diff --git a/ucastnici/6.8.2016/jvaclavik.md b/ucastnici/6.8.2016/jvaclavik.md
deleted file mode 100644
index 3b4ca1b..0000000
--- a/ucastnici/6.8.2016/jvaclavik.md
+++ /dev/null
@@ -1 +0,0 @@
-Trochu víc se mi líbil kurz o Ionicu, jak tady v Alze byl předtím, ale jinak dobrý.
\ No newline at end of file
diff --git a/ucastnici/6.8.2016/nodonisko.md b/ucastnici/6.8.2016/nodonisko.md
deleted file mode 100644
index 63cdba8..0000000
--- a/ucastnici/6.8.2016/nodonisko.md
+++ /dev/null
@@ -1 +0,0 @@
-Nejlepší kurz ever <3 <3 <3
\ No newline at end of file
diff --git a/ucastnici/6.8.2016/petr_kysela.md b/ucastnici/6.8.2016/petr_kysela.md
deleted file mode 100644
index 57d61cd..0000000
--- a/ucastnici/6.8.2016/petr_kysela.md
+++ /dev/null
@@ -1,3 +0,0 @@
-# GIT
-
-- nauči se *.kit
diff --git a/ucastnici/6.8.2016/petrhamacek.md b/ucastnici/6.8.2016/petrhamacek.md
deleted file mode 100644
index 6d35564..0000000
--- a/ucastnici/6.8.2016/petrhamacek.md
+++ /dev/null
@@ -1,2 +0,0 @@
-Tenhle kurz je parádní. Jenom mi trochu uniká ta pokročilejší druhá část. 
-Na netu v mým forku vidím větem dev, ale u sebe v clonu jí nevidím.
diff --git a/ucastnici/6.8.2016/qeef.md b/ucastnici/6.8.2016/qeef.md
deleted file mode 100644
index 550ac0c..0000000
--- a/ucastnici/6.8.2016/qeef.md
+++ /dev/null
@@ -1 +0,0 @@
-content of some file
diff --git a/ucastnici/6.8.2016/snizemic.md b/ucastnici/6.8.2016/snizemic.md
deleted file mode 100644
index 5d5554b..0000000
--- a/ucastnici/6.8.2016/snizemic.md
+++ /dev/null
@@ -1 +0,0 @@
-Naprosto skvělý kurz, jsem rád, že už tomu konečně všemu rozumím!!!
\ No newline at end of file
diff --git a/ucastnici/6.8.2016/strakator.md b/ucastnici/6.8.2016/strakator.md
deleted file mode 100644
index ee9869c..0000000
--- a/ucastnici/6.8.2016/strakator.md
+++ /dev/null
@@ -1 +0,0 @@
-Fast & Furious :)
diff --git a/ucastnici/6.8.2016/vahyThe.md b/ucastnici/6.8.2016/vahyThe.md
deleted file mode 100644
index 8499d13..0000000
--- a/ucastnici/6.8.2016/vahyThe.md
+++ /dev/null
@@ -1 +0,0 @@
-vim je best
diff --git a/ucastnici/6.8.2016/vojtatranta.md b/ucastnici/6.8.2016/vojtatranta.md
deleted file mode 100644
index f84e48d..0000000
--- a/ucastnici/6.8.2016/vojtatranta.md
+++ /dev/null
@@ -1 +0,0 @@
-Tenhle kurz je špatnej.

From ca09d197b4b9af79235b6570a610d0c8d7622704 Mon Sep 17 00:00:00 2001
From: Daniel Suchy <suchydan@gmail.com>
Date: Tue, 24 Jan 2017 14:37:06 +0100
Subject: [PATCH 2/9] Readme for Olomouc webdev

---
 README.md | 41 +++++++++++++++++++----------------------
 1 file changed, 19 insertions(+), 22 deletions(-)

diff --git a/README.md b/README.md
index 3c73b52..0bb2770 100644
--- a/README.md
+++ b/README.md
@@ -8,38 +8,35 @@ 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ří také Nikitu Mironovi, která je zakladatelem pražského Webdev / JS evenings klub, který mě inspiroval pro založení
+toho našeho olomouckého.
 
-Po mně následuje Petr a jeho kurz o automatizaci vývoje.
+Další 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!
 
-Za to, že umím git vděčím hlavně chlapcům [@lukas_rychtecky](https://twitter.com/lukasrychtecky) a [@jankuca](https://twitter.com/jankuca)
+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ě Vojtovi Trantovi [@iVojta](https://twitter.com/ivojta), který je také 
+původní autorem tohoto kurzu a materiálů, které budeme používat.
 
 ## 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
 
-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/)
+[DanielSuchy.cz](https://danielsuchy.cz)
+[suchydan@gmail.com](suchydan@gmail.com)
 
 ## 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 />
\ No newline at end of file

From e2b1e3c4300f742b98c41f1aa8c8eec8371afdec Mon Sep 17 00:00:00 2001
From: Daniel Suchy <suchydan@gmail.com>
Date: Tue, 24 Jan 2017 14:40:43 +0100
Subject: [PATCH 3/9] readme paragraph reorder in about section

---
 README.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/README.md b/README.md
index 0bb2770..9ca0e85 100644
--- a/README.md
+++ b/README.md
@@ -11,10 +11,7 @@ a to i těch hluboko v historii.
 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.
 
-Velký dík patří také Nikitu Mironovi, která je zakladatelem pražského Webdev / JS evenings klub, který mě inspiroval pro založení
-toho našeho olomouckého.
-
-Další 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
+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!
 
 Tento kurz bude z budu přednášet já [Daniel Suchý](https://danielsuchy.cz/), JS vývojář v [U+](https://u.plus/).
@@ -22,6 +19,9 @@ Tento kurz bude z budu přednášet já [Daniel Suchý](https://danielsuchy.cz/)
 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)

From 23ce7c164b7d22c38da5e4cc0786314538a13324 Mon Sep 17 00:00:00 2001
From: Daniel Suchy <suchydan@gmail.com>
Date: Tue, 24 Jan 2017 14:41:50 +0100
Subject: [PATCH 4/9] line breaks in readme

---
 README.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/README.md b/README.md
index 9ca0e85..495b3fa 100644
--- a/README.md
+++ b/README.md
@@ -28,10 +28,10 @@ toho našeho olomouckého.
 3. [Advanced Git](./advanced.md)
 
 
-Daniel Suchý
-[Webdev klub - OLOMOUC](https://www.facebook.com/groups/1874049622825379/)
-[DanielSuchy.cz](https://danielsuchy.cz)
-[suchydan@gmail.com](suchydan@gmail.com)
+## 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/)

From 05b77da6b3f7c924d148956aad148d36409994e6 Mon Sep 17 00:00:00 2001
From: Daniel Suchy <suchydan@gmail.com>
Date: Tue, 24 Jan 2017 17:49:43 +0100
Subject: [PATCH 5/9] branching task

---
 commit-branch.md | 185 +++++++++++++++++++++++------------------------
 web/index.html   |  29 ++++++++
 web/style.css    |   0
 3 files changed, 121 insertions(+), 93 deletions(-)
 create mode 100644 web/index.html
 create mode 100644 web/style.css

diff --git a/commit-branch.md b/commit-branch.md
index 5ea7113..812bc79 100644
--- 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 "John Doe"
+$ git config --global user.email johndoe@example.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++ na:
+```
+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,51 +199,11 @@ $ 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.
-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:
-```
-i
-```
-
-Nyní napíšeme nějakou commit message - to, co jsme udělali. V našem případě asi něco jako:
-```
-přidání souboru pro poznámky notes.md
-```
-
-A pak pryč z VIMu:
-```
-<esc>:wq
-```
-Nebo:
-```
-<esc>
-shift + ZZ
-```
-
-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
-```
-
-Jasně, nikoho nebaví se furt přepínat do VIMu. Proto existuje zkratka, kterou používám:
-```
-$ git commit -m "commit messsage"
-```
-A rovnou si na ní uděláme aliasík, ne? Co takle, kdyby `git cm "commit message"` bylo to samé?
-```
-$ git config --global alias.cm 'git commit -m'
-```
-Vyzkoušíme si:
-```
-// udělat změnu
-$ git add notes.md
-$ git cm 'moje message'
+// vytvoříme nový commit
+$ git commit -m "moje messsage"
 ```
 
 Hotovo, commit udělán, co teď? Jdeme dál commitovat!
@@ -240,7 +224,7 @@ No, smazat. Ono smazat commit je poměrně dost těžká práce. Ukážeme si.
 Nejdřív si ukážeme seznam všech commitů - příkaz **log**, které jsme doteď vytvořili - nelekejte se, jsou tam i moje původní a to je dobře.
 
 ```
-// zobrazit seznam commitů na aktuální branch
+// zobrazit seznam commitů na aktuální branchi
 $ git log
 // hezčí zobrazí seznamu
 $ git log --pretty=oneline -n 50 --graph --abbrev-commit
@@ -260,7 +244,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 +254,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 +272,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 +298,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 +315,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**:
 ```
@@ -424,36 +409,40 @@ Každý Commit má jenom jednoho předka, ale nikde není psáno, že jeden comm
 Pokud vytvoříme v Gitu branch (větev) tak umožňujeme, aby jeden Commit měl více potomků a tím se nám vývoj větví.
 
 ### K čemu to je dobrý?
-Představme si, že chceme mít naše poznámky v angličtině. Do teď jsme si je psali česky. Jak to udělat, abychom to měli i v angličtině? No, pokud máme jenom jednu větev, tak jediný způsob je udělat commity, které češtinu přeloží do angličtiny, ale tím pádem ztratíme čestinu, která bude utopená někde v historii.
+Typický příklad že života je např práce na webových stránkách. Pracujete na nějaké nové funkci například 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.
 
-Nejlepší by bylo zároveň dál psát česky a zároveň překládat češtinu do angličtiny. Prostě vytvořit si anglickou větev.
+Ale pokud máte GIT, použijete elegatní způsob pomocí větví (branch).
 
 ### Jak na branchování
 Jednoduše se dá zjistit na jaké branch jsme teď + zobrazení všech větví:
 ```
 $ git branch
-
-// rychle udělat alias
-$ git config --global alias.b branch
 ```
 A zobrazí se nám **master**.
 
 **Master** je další pojem z Gitu. Master je ustálený název pro hlavní větev vývoje, do které jsou spojeny (mergnuty) vývojové větve. Tahle větev by měla být stabilní a dokonce by se do ní přímo nemělo commitovat - k tomu se dostaneme až budeme dělat `git flow`.
 
-Pro naše účely ale nebudeme tak striktní a řekneme si, že naše hlavní vývojová větev **master** bude větev v češtině a větev **english** jí bude následovat.
+Pro naše účely ale nebudeme tak striktní a řekneme si, že naše hlavní vývojová větev **master**.
+
+Pustíme se tedy do práce a vytvoříme jsi novou větev pro novou featuru.
 
 #### Vytvoření vývojové větve
 Vytvořit **branch** - větev se dá mnoha způsoby.
 ```
 // klasicky
-$ git branch english
+$ git branch feature
 ```
-Stalo se to, že jsme z rodičovské verze `master` vytvořili novou větev, která se jmenuje `english`.
+Stalo se to, že jsme z rodičovské verze `master` vytvořili novou větev, která se jmenuje `feature`.
 
 `git checkout` se používá nejen pro smazání unstaged změn, ale taky k přepnutí branchí:
 ```
-$ git checkout english
-$ git b
+$ git checkout feature
+$ git branch
 ```
 Ukáže se nám seznam branchí a naše aktuální, na kterou jsme se přepnul přes `git checkout`.
 
@@ -461,63 +450,73 @@ Tohle je ale zdlouhavý způsob. Sám `git branch` používám jenom k zobrazen
 ```
 // zpět na master
 $ git checkout master
-$ git b // jsme v masteru
+$ git branch // jsme v masteru
 
 // smazání větve
-$ git branch -D english
+$ git branch -D feature
 
 // vytvoření větve english a přepnutí do ní rovnou
-$ git checkout -b english
-$ git b // jsme v english větvi
+$ git checkout -b feature
+$ git branch 
+// jsme v feature větvi
 ```
 No a co teď?
 
-Když nyní commitneme, tak commit bude stále pouze na této větvi. Tak do toho, uděláme si soubor, který bude pouze pro tuhle větev.
+Když nyní commitneme, tak commit bude stále pouze na této větvi. Tak do toho, uděláme si pár změn, který budou pouze pro tuhle větev.
+Např. máme za úkol upravit menu, přidat nějaké nové odkazy a odebrat některé staré. Jakmile máme sadu změn hotovou, můžeme je commitnout. 
 ```
-$ touch english.md
-$ git add english.md
-$ git cm "add file in english on english branch"
+$ git add --all
+// nebo můžeme přidat jen složku web
+$ git add web/
+$ git cm "new menu"
 ```
-Nyní, pokud se přepneme do masteru soubor `english.md` zmizí, protože je vedený pouze na větvi `english`.
 
-A pozor, pokud si zobrazíme `git l`. Tak vidíme commit, ze kterého vychází branch `english` a pokud uděláme nyní další commit tak se stane, že tenhle commit, ze kterého vychází větev `english` bude mít dva potomky.
+Nyní, nám přichází email nebo telefonát že je nutně potřeba něco opravit. Zatím ještě nechceme naše změnit propisovat na web protože ještě nejsou schváleny a otestovány. Tak jak na to?
+
+Přepneme do masteru, pomocí `checkout` a všechny změny provedené v menu v souboru index.html zmizí, protože ty byly provedeny na větvi `feature`.
+
+A pozor, pokud si zobrazíme `git l`. Tak vidíme commit, ze kterého vychází branch `feature` a pokud bychom udělali nyní další commit tak se stane, že tenhle commit, ze kterého vychází větev `feature` bude mít dva potomky.
 
 To je v pohodě. Ale horší budou jiné věci...
 
-Nyní, pokud chceme ukázat větvení, tak se přepneme zpátky do masteru a uděláme commit:
+Nyní, pokud chceme ukázat větvení, tak se přepneme zpátky do masteru a uděláme commit s požadovaným hotfixem, v našem případě to bude např. úprava patičky:
 ```
 $ git checkout master
-$ touch czech.md
 $ git add --all
-$ git cm "added file in czech on master branch"
+$ git cm "footer email change"
 ```
 Zkusíme příkaz `git l`, pokud nemáte nastavený stejně alias, napište:
 
-```
-git log --graph --all --decorate --pretty=oneline --abbrev-commit
-```
 Voilà - už nám rostou větvičky ze stromu a bude hůř!
 
-Resetneme si bordel, co jsme udělali na obou brančích a přepneme se do `english` a přeložíme si kus `notes.md` a změnu comitneme.
+No a co se teď stalo? My jsme aktulizovali větev `master`, ale pokud se přepneme do `feature`, tak zde ta změna není vidět.
 
-Teď to začne bejt hustý. Máme tedy kousek textu přeloženej a teď si představíme, že normálně píšeme poznámky dál v češtině na větvi `master`.
+Proč?
 
-Takže se přepneme do `masteru` zase zapíšeme několik poznámek do `notes.md` a změnu commitneme.
+Odpověď se nachází v `git log` nebo v `git l`.
 
-No a co se teď stalo? My jsme aktulizovali větev `master`, ale pokud se přepneme do `english`, tak zde ta změna není vidět.
+Jde o to, že když jsme vytvářeli branch `feature` tak ona se vytvoří z bodu, který byl tehdy aktuální. Commity, které nyní vytvoříme na rodiči se nepromítnou, do `feature` - logicky.
 
-Proč?
+Proto je třeba nějak říct větvi `feature`, aby se aktualizovala a my mohli otestovat naše změny i s hotfixem dál, jak to uděláme?
 
-Odpověď se nachází v `git log` nebo v `git l`.
+### 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.
 
-Jde o to, že když jsme vytvářeli branch `english` tak ona se vytvoří z body, který byl tehdy aktuální. Commity, které nyní vytvoříme na rodiči se nepromítnou, do `english` - logicky.
+`Merge commit` se dá snadno smazat normálně pomocí `git reset --hard`.
+
+Takže namergujeme vetěv master do naší větve `feature` pomocí příkazu:
 
-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?
+```
+$ 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`.
 
-Nyní je čas si prohlédnout `git l`. A vidíme, že `english` vychází z neaktuálního commitu v `master`. Nyní zavoláme:
+Nyní je čas si prohlédnout `git l`. A vidíme, že `feature` vychází z neaktuálního commitu v `master`. Nyní zavoláme:
 ```
 $ git rebase master
 ```
@@ -528,7 +527,7 @@ no a teď:
 $ git l
 ```
 
-A strom je pryč, neboť není potřeba, vše je aktuální. Ukazatelé na předky byly posunuty, tudíž nejaktuálněší commit z celého repozitáře je poslední commit na větvi `english`.
+A strom je pryč, neboť není potřeba, vše je aktuální. Ukazatelé na předky byly posunuty, tudíž nejaktuálněší commit z celého repozitáře je poslední commit na větvi `feature`.
 
 UF!
 
diff --git a/web/index.html b/web/index.html
new file mode 100644
index 0000000..943e719
--- /dev/null
+++ b/web/index.html
@@ -0,0 +1,29 @@
+<!DOCTYPE html>
+<html lang="en">
+  <head>
+    <meta charset="utf-8">
+    <title>Webdev Olomouc - přednáška GIT</title>
+    <link rel="stylesheet" href="style.css">
+  </head>
+  <body>
+    <header>
+        <h1>Webdev Olomouc - přednáška GIT</h1>
+    </header>
+    <menu>
+        <ul>
+            <li><a href="https://www.facebook.com/groups/1874049622825379/">FB skupina</a></li>
+            <li><a href="https://www.facebook.com/events/1904779056420262/">FB událost</a></li>
+            <li><a href="http://danielsuchy.cz">Daniel Suchý</a>
+        </ul>
+    </menu>
+    <content>
+        <p>
+            <h1>Ahoj světe</h1>
+            Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
+        </p>
+    </content>
+    <footer style="text-align: center">
+        @danielsuchy
+    </footer>
+  </body>
+</html>
\ No newline at end of file
diff --git a/web/style.css b/web/style.css
new file mode 100644
index 0000000..e69de29

From c7b65fe566170c879d03363067d90af10f327e2d Mon Sep 17 00:00:00 2001
From: Daniel Suchy <suchydan@gmail.com>
Date: Sat, 28 Jan 2017 23:17:12 +0100
Subject: [PATCH 6/9] Finalizing before PR

---
 commit-branch.md | 188 +++++++++++++++++++++++++++++++++++------------
 1 file changed, 143 insertions(+), 45 deletions(-)

diff --git a/commit-branch.md b/commit-branch.md
index 812bc79..bafe6ce 100644
--- a/commit-branch.md
+++ b/commit-branch.md
@@ -29,8 +29,8 @@ Po nainstalovaní gitu je potřeba provést základní nastavení. Nejdůležit
 vytvoření nového commitu.
 
 ```
-$ git config --global user.name "John Doe"
-$ git config --global user.email johndoe@example.com
+$ 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`
@@ -39,7 +39,7 @@ Pokud chceme předejít adrenalinovým zážitkům s VIMem, hodí se nastavit v
 ```
 git config --global core.editor nano
 ```
-Nebo stejný příkaz na Windows pro editor Notepad++ na:
+Nebo stejný příkaz na Windows pro editor Notepad++:
 ```
 git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -nosession"
 ```
@@ -202,8 +202,49 @@ 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
 
-// vytvoříme nový commit
-$ git commit -m "moje messsage"
+$ git commit
+```
+**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:
+```
+i
+```
+
+Nyní napíšeme nějakou commit message - to, co jsme udělali. V našem případě asi něco jako:
+```
+přidání souboru pro poznámky notes.md
+```
+
+A pak pryč z VIMu:
+```
+<esc>:wq
+```
+Nebo:
+```
+<esc>
+shift + ZZ
+```
+
+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
+```
+
+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"
+```
+A rovnou si na ní uděláme aliasík, ne? Co takle, kdyby `git cm "commit message"` bylo to samé?
+```
+$ git config --global alias.cm 'git commit -m'
+```
+Vyzkoušíme si:
+```
+// udělat změnu
+$ git add notes.md
+$ git cm 'moje message'
 ```
 
 Hotovo, commit udělán, co teď? Jdeme dál commitovat!
@@ -224,12 +265,12 @@ No, smazat. Ono smazat commit je poměrně dost těžká práce. Ukážeme si.
 Nejdřív si ukážeme seznam všech commitů - příkaz **log**, které jsme doteď vytvořili - nelekejte se, jsou tam i moje původní a to je dobře.
 
 ```
-// zobrazit seznam commitů na aktuální branchi
+// zobrazit seznam commitů na aktuální branch
 $ 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
 
@@ -409,40 +450,36 @@ Každý Commit má jenom jednoho předka, ale nikde není psáno, že jeden comm
 Pokud vytvoříme v Gitu branch (větev) tak umožňujeme, aby jeden Commit měl více potomků a tím se nám vývoj větví.
 
 ### K čemu to je dobrý?
-Typický příklad že života je např práce na webových stránkách. Pracujete na nějaké nové funkci například 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.
+Představme si, že chceme mít naše poznámky v angličtině. Do teď jsme si je psali česky. Jak to udělat, abychom to měli i v angličtině? No, pokud máme jenom jednu větev, tak jediný způsob je udělat commity, které češtinu přeloží do angličtiny, ale tím pádem ztratíme čestinu, která bude utopená někde v historii.
 
-Ale pokud máte GIT, použijete elegatní způsob pomocí větví (branch).
+Nejlepší by bylo zároveň dál psát česky a zároveň překládat češtinu do angličtiny. Prostě vytvořit si anglickou větev.
 
 ### Jak na branchování
 Jednoduše se dá zjistit na jaké branch jsme teď + zobrazení všech větví:
 ```
 $ git branch
+
+// rychle udělat alias
+$ git config --global alias.b branch
 ```
 A zobrazí se nám **master**.
 
 **Master** je další pojem z Gitu. Master je ustálený název pro hlavní větev vývoje, do které jsou spojeny (mergnuty) vývojové větve. Tahle větev by měla být stabilní a dokonce by se do ní přímo nemělo commitovat - k tomu se dostaneme až budeme dělat `git flow`.
 
-Pro naše účely ale nebudeme tak striktní a řekneme si, že naše hlavní vývojová větev **master**.
-
-Pustíme se tedy do práce a vytvoříme jsi novou větev pro novou featuru.
+Pro naše účely ale nebudeme tak striktní a řekneme si, že naše hlavní vývojová větev **master** bude větev v češtině a větev **english** jí bude následovat.
 
 #### Vytvoření vývojové větve
 Vytvořit **branch** - větev se dá mnoha způsoby.
 ```
 // klasicky
-$ git branch feature
+$ git branch english
 ```
-Stalo se to, že jsme z rodičovské verze `master` vytvořili novou větev, která se jmenuje `feature`.
+Stalo se to, že jsme z rodičovské verze `master` vytvořili novou větev, která se jmenuje `english`.
 
 `git checkout` se používá nejen pro smazání unstaged změn, ale taky k přepnutí branchí:
 ```
-$ git checkout feature
-$ git branch
+$ git checkout english
+$ git b
 ```
 Ukáže se nám seznam branchí a naše aktuální, na kterou jsme se přepnul přes `git checkout`.
 
@@ -450,54 +487,58 @@ Tohle je ale zdlouhavý způsob. Sám `git branch` používám jenom k zobrazen
 ```
 // zpět na master
 $ git checkout master
-$ git branch // jsme v masteru
+$ git b // jsme v masteru
 
 // smazání větve
-$ git branch -D feature
+$ git branch -D english
 
 // vytvoření větve english a přepnutí do ní rovnou
-$ git checkout -b feature
-$ git branch 
-// jsme v feature větvi
+$ git checkout -b english
+$ git b // jsme v english větvi
 ```
 No a co teď?
 
-Když nyní commitneme, tak commit bude stále pouze na této větvi. Tak do toho, uděláme si pár změn, který budou pouze pro tuhle větev.
-Např. máme za úkol upravit menu, přidat nějaké nové odkazy a odebrat některé staré. Jakmile máme sadu změn hotovou, můžeme je commitnout. 
+Když nyní commitneme, tak commit bude stále pouze na této větvi. Tak do toho, uděláme si soubor, který bude pouze pro tuhle větev.
 ```
-$ git add --all
-// nebo můžeme přidat jen složku web
-$ git add web/
-$ git cm "new menu"
+$ touch english.md
+$ git add english.md
+$ git cm "add file in english on english branch"
 ```
+Nyní, pokud se přepneme do masteru soubor `english.md` zmizí, protože je vedený pouze na větvi `english`.
 
-Nyní, nám přichází email nebo telefonát že je nutně potřeba něco opravit. Zatím ještě nechceme naše změnit propisovat na web protože ještě nejsou schváleny a otestovány. Tak jak na to?
-
-Přepneme do masteru, pomocí `checkout` a všechny změny provedené v menu v souboru index.html zmizí, protože ty byly provedeny na větvi `feature`.
-
-A pozor, pokud si zobrazíme `git l`. Tak vidíme commit, ze kterého vychází branch `feature` a pokud bychom udělali nyní další commit tak se stane, že tenhle commit, ze kterého vychází větev `feature` bude mít dva potomky.
+A pozor, pokud si zobrazíme `git l`. Tak vidíme commit, ze kterého vychází branch `english` a pokud uděláme nyní další commit tak se stane, že tenhle commit, ze kterého vychází větev `english` bude mít dva potomky.
 
 To je v pohodě. Ale horší budou jiné věci...
 
-Nyní, pokud chceme ukázat větvení, tak se přepneme zpátky do masteru a uděláme commit s požadovaným hotfixem, v našem případě to bude např. úprava patičky:
+Nyní, pokud chceme ukázat větvení, tak se přepneme zpátky do masteru a uděláme commit:
 ```
 $ git checkout master
+$ touch czech.md
 $ git add --all
-$ git cm "footer email change"
+$ git cm "added file in czech on master branch"
 ```
 Zkusíme příkaz `git l`, pokud nemáte nastavený stejně alias, napište:
 
+```
+git log --graph --all --decorate --pretty=oneline --abbrev-commit
+```
 Voilà - už nám rostou větvičky ze stromu a bude hůř!
 
-No a co se teď stalo? My jsme aktulizovali větev `master`, ale pokud se přepneme do `feature`, tak zde ta změna není vidět.
+Resetneme si bordel, co jsme udělali na obou brančích a přepneme se do `english` a přeložíme si kus `notes.md` a změnu comitneme.
+
+Teď to začne bejt hustý. Máme tedy kousek textu přeloženej a teď si představíme, že normálně píšeme poznámky dál v češtině na větvi `master`.
+
+Takže se přepneme do `masteru` zase zapíšeme několik poznámek do `notes.md` a změnu commitneme.
+
+No a co se teď stalo? My jsme aktulizovali větev `master`, ale pokud se přepneme do `english`, tak zde ta změna není vidět.
 
 Proč?
 
 Odpověď se nachází v `git log` nebo v `git l`.
 
-Jde o to, že když jsme vytvářeli branch `feature` tak ona se vytvoří z bodu, který byl tehdy aktuální. Commity, které nyní vytvoříme na rodiči se nepromítnou, do `feature` - logicky.
+Jde o to, že když jsme vytvářeli branch `english` tak ona se vytvoří z body, který byl tehdy aktuální. Commity, které nyní vytvoříme na rodiči se nepromítnou, do `english` - logicky.
 
-Proto je třeba nějak říct větvi `feature`, aby se aktualizovala a my mohli otestovat naše změny i s hotfixem dál, jak to uděláme?
+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.
@@ -507,7 +548,7 @@ Je zvlášní druh commitu, který drží ukazele na commity z branche, kterou m
 
 `Merge commit` se dá snadno smazat normálně pomocí `git reset --hard`.
 
-Takže namergujeme vetěv master do naší větve `feature` pomocí příkazu:
+Takže namergujeme vetěv master do naší větve `english` pomocí příkazu:
 
 ```
 $ git merge master
@@ -516,7 +557,7 @@ $ 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`.
 
-Nyní je čas si prohlédnout `git l`. A vidíme, že `feature` vychází z neaktuálního commitu v `master`. Nyní zavoláme:
+Nyní je čas si prohlédnout `git l`. A vidíme, že `english` vychází z neaktuálního commitu v `master`. Nyní zavoláme:
 ```
 $ git rebase master
 ```
@@ -527,7 +568,7 @@ no a teď:
 $ git l
 ```
 
-A strom je pryč, neboť není potřeba, vše je aktuální. Ukazatelé na předky byly posunuty, tudíž nejaktuálněší commit z celého repozitáře je poslední commit na větvi `feature`.
+A strom je pryč, neboť není potřeba, vše je aktuální. Ukazatelé na předky byly posunuty, tudíž nejaktuálněší commit z celého repozitáře je poslední commit na větvi `english`.
 
 UF!
 
@@ -547,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
+```
 

From 8e5139a8c0dd888c0c1816d2627081ef28fb9d4c Mon Sep 17 00:00:00 2001
From: Daniel Suchy <suchydan@gmail.com>
Date: Sat, 28 Jan 2017 23:25:28 +0100
Subject: [PATCH 7/9] Added useful links

---
 README.md | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/README.md b/README.md
index 495b3fa..01f9ed4 100644
--- a/README.md
+++ b/README.md
@@ -27,6 +27,10 @@ toho našeho olomouckého.
 2. [Git Flow](./git-flow.md)
 3. [Advanced Git](./advanced.md)
 
+## 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)
 
 ## Daniel Suchý
 [Webdev klub - OLOMOUC](https://www.facebook.com/groups/1874049622825379/) <br />

From d7d9a94a05c3f136a81c57cdaa889179135b3b71 Mon Sep 17 00:00:00 2001
From: Daniel Suchy <suchydan@gmail.com>
Date: Tue, 31 Jan 2017 16:47:58 +0100
Subject: [PATCH 8/9] Git flow updated

---
 git-flow.md | 29 ++++++++++++++++-------------
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/git-flow.md b/git-flow.md
index 983ac72..6675375 100644
--- a/git-flow.md
+++ b/git-flow.md
@@ -18,9 +18,8 @@ Zajímavý je pro nás obrázek Applu. Protože takle nějak vypadá Git flow.
 
 ### Kdo je Steve Jobs?
 Ta červená tečka uprostřed je v našem případě náš společný repozitář, do kterého všichni přispíváme.
-Minulou přednášku jsme si forknuli repozitář ten špatný, a dneska si forkneme už ten správný!
 
-https://github.com/webdev-js-evenings/git-workshop
+https://github.com/Nodonisko/git-workshop
 
 A naklonujte si ho, jako v poslední přednášce! (omlouvám se za komplikace)
 
@@ -49,7 +48,7 @@ V první řadě potřebujeme nějaké **issues**. Issue nebo taky task je prost
 A každý ho vyřešíme pull requestem.
 
 Issue zní:
-- Vytvořte soubor `ucastnici/6.8.2016/< vase username na githubu >.md`
+- Vytvořte soubor `ucastnici/31.2.2017/< vase username na githubu >.md`
 - napište tam vaší recenzi tohodle kurzu - stačí na dva řádky
 
 Prakticky ve všech aplikacích na sledování issues má každý takový úkol nějaké `ID`. Github ID používá samozřejmě taky a hojně. Snadno se přes `issue ID` páruje issue a pull request. Ukážeme si.
@@ -80,7 +79,7 @@ Tak šup šup! Vytváře commity umíme, udělejte commit, který splní to, co
 
 Je také good practise psát do commit message issue ID a co s ní který commit dělá např:
 ```
-Add file /ucastnici/6.8.2016/jenicek.md
+Add file /ucastnici/31.2.2017/jenicek.md
 closes #4234
 ```
 
@@ -96,14 +95,17 @@ git push origin < vase branch >
 ```
 Tak `git` pošle commity, které jste udělali do vašeho forku a vytvoří tam novou branch. Do toho.
 
-A mrkneme se na internát!
+A mrkneme se na internet!
 
 #### Vytvoření pull requestu
+
+**----------------- Spatny jmena branchi??? --------------**
+
 Pokud si na Githubu klikneme na naší branch, ta se nám tam zobrazí možnost udělat pull request. Buďto klikneme sem nebo jde do záložky pull request a vytvoříme ho stejnou cestou.
 
 Pokud jsme ve forku, tak se automaticky vyplní repozitář kam chceme poslat pull request a dokonce se vybere i nějaká branch.
 
-My ale víme, že jsme vytvořili pull request z branch `dev` a tudíž chceme také poslat pull request do branch `next` v repozitáři `webdev-js-evenings/git-workshop`. To, jak budou vytvářet release a verzování hlavního repozitáře už je na jeho správcích. My prostě pošlete pull request do dev branche.
+My ale víme, že jsme vytvořili pull request z branch `feature-*` a tudíž chceme také poslat pull request do branch `dev` v repozitáři `Nodonisko/git-workshop`. To, jak budou vytvářet release a verzování hlavního repozitáře už je na jeho správcích. My prostě pošlete pull request do dev branche.
 
 Vyplní se sám titulek podle posledního commitu. A zároveň je možné a důležité spojit pull request s issue ID. Proto je rozumné do popisku napsat:
 ```
@@ -124,7 +126,7 @@ Osobně si **nedovedu** představit dělat vážně projekt, kterej by neměl ž
 
 Sobě jsem udělal komentář, abych něco změnil a aktualizoval změny, mrkneme se na to.
 
-Ke změně pull requestu stačí jenom aktualizovat branch ve svém forku - to umíme, buďto tam pushneme nové commity nebo uděláme `ammend` udělám `ammend`, aby bylo vidět, co se stane.
+Ke změně pull requestu stačí jenom aktualizovat branch ve svém forku - to umíme, buďto tam pushneme nové commity nebo uděláme `ammend`, aby bylo vidět, co se stane.
 
 **A všichni se mnou!!**
 
@@ -140,10 +142,10 @@ Není :-D
 #### Je krásné být aktuální
 Tohle byla pohoda... Jak ale synchronizovat ty změny?
 
-Tak, když jsem přijmul a mergnul všechny pull requesty, tak se automaticky mergnuly do větve `dev` v repozitáři `webdev-js-evenings/git-workshop`.
+Tak, když jsem přijmul a mergnul všechny pull requesty, tak se automaticky mergnuly do větve `dev` v repozitáři `Nodonisko/git-workshop`.
 Nyní, pokud zadám nový úkol, například - podepište si svojí recenzi, tak pořád platí, že všehny pull requesty musíme vytváře z aktuální branche `dev`. Jak jí ale aktualizujeme?
 
-No, musíme si přidat `webdev-js-evenings/git-workshop` jako **remote** repozitář a z něho si změny stahovat.
+No, musíme si přidat `Nodonisko/git-workshop` jako **remote** repozitář a z něho si změny stahovat.
 
 ##### Přidání remote
 Přidání remote je jednoduché a nejdřív si je hezky zobrazíme:
@@ -153,7 +155,7 @@ git remote -v
 A vidíme jen origin, paráda. Teď zkusíme přidat.
 
 ```
-git remote add origin https://github.com/webdev-js-evenings/git-workshop.git
+git remote add origin https://github.com/Nodonisko/git-workshop.git
 ```
 Uh, to nejde, co? No to je proto, že jsem pojmenoval tenhle repozitář jako `origin` a nejde mít dva repozitáře pojmenované stejně.
 
@@ -176,7 +178,7 @@ Jdeme aktualizovat
 ##### Actually buďme aktuální
 Zatím to je snad všechno nějak jasný, asi ne, nevadí, cvik je cvik.
 
-Teď si teda chceme konečně udělat naší `dev` větev aktuální tak, aby byla ve stejném stavu jako `dev` větev v `webdev-js-evenings/git-workshop`. Je to proto, abychom měli pořád aktuální změny a neměli v tom bordel a abychom mohli vyvíjet dál nad prací našich kolegů.
+Teď si teda chceme konečně udělat naší `dev` větev aktuální tak, aby byla ve stejném stavu jako `dev` větev v `Nodonisko/git-workshop`. Je to proto, abychom měli pořád aktuální změny a neměli v tom bordel a abychom mohli vyvíjet dál nad prací našich kolegů.
 
 Jak jí na to příkaz? Je jich více...
 
@@ -227,6 +229,7 @@ Pokud ale pořád chceme používat normálně lokální branch `dev` a nechceme
 git checkout dev
 git rebase origin/dev
 ```
+
 Můžete si to vyzkoušet tak, že si resetnete commity z branche `dev`.
 A je to!
 
@@ -242,7 +245,7 @@ No a co teda vy? Máte vytvořenou feature branch z commitu, kde ještě soubory
 
 Tak první krok je jasný, budete muset svojí větev `dev` aktualizovat a pak svojí feature branch rebasnou na aktuální `dev`, to vám ale nepůjde, protože zde bude konflit...
 
-**Úkol:** Všichni prosím udělejte pull request s commmitem, ve kterém do souboru `git-flow/good-music.md` napíšete odkaz na nějakou hezkou písničky - pro inspiraci tam už nějaké kvalitní songy jsou.
+**Úkol:** Všichni prosím udělejte pull request s commmitem, ve kterém do souboru `git-flow/good-music-ol.md` napíšete odkaz na nějakou hezkou písničky - pro inspiraci tam už nějaké kvalitní songy jsou.
 
 Jakmile budete mít pull request, tak já commitem smažu a přesunu tento soubor jinam a uvidíme, co se bude dít.
 
@@ -348,6 +351,6 @@ git push -f < nas remote > < feature branch >
 **POZOR:** Force pushování mění historii na remotu, můžete si tak něco smazat! Nebo tak něco smazat kolegům!
 
 ## Už to všichni umíme
-Proto dávám všem úkol. Každý najděte v mých dokumentech nějakou chybu - pravopisnou, překlep atd. Napište issue na github, udělejte vyvoněný pull request a já to mergnu a pak vydáme verzi `0.2`!!
+Proto dávám všem úkol. Každý najděte v mých dokumentech nějakou chybu - pravopisnou, překlep atd. Napište issue na github, udělejte vyvoněný pull request a já to mergnu a pak vydáme verzi `0.3`!!
 
 

From 7bc180b1291e9ca4388e54a56cd501328d9cc301 Mon Sep 17 00:00:00 2001
From: Daniel Suchy <suchydan@gmail.com>
Date: Tue, 31 Jan 2017 16:48:38 +0100
Subject: [PATCH 9/9] Added some good music

---
 git-flow/good-music-ol.md | 6 ++++++
 1 file changed, 6 insertions(+)
 create mode 100644 git-flow/good-music-ol.md

diff --git a/git-flow/good-music-ol.md b/git-flow/good-music-ol.md
new file mode 100644
index 0000000..c9d59fc
--- /dev/null
+++ b/git-flow/good-music-ol.md
@@ -0,0 +1,6 @@
+Imagine Dragons - Demons
+Ed Sheeran - I See Fire
+Parov Stelar - Booty Swing
+Electro Swing Collection
+"Freedom" by Anthony Hamilton & Elayna Boynton
+SAIL - AWOLNATION 
\ No newline at end of file