Skip to content

Commit fa6864b

Browse files
committed
add branching
1 parent 9275259 commit fa6864b

File tree

1 file changed

+138
-5
lines changed

1 file changed

+138
-5
lines changed

README.md

Lines changed: 138 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -253,7 +253,7 @@ $ git log
253253
// hezčí zobrazí seznamu
254254
$ git log --pretty=oneline -n 50 --graph --abbrev-commit
255255
// uděláme na něj alias
256-
$ git config --globa alias.l 'log --pretty=oneline -n 50 --graph --abbrev-commit'
256+
$ git config --globa alias.l 'log --pretty=oneline --graph --abbrev-commit --branches --decorate -n 100'
257257
//vyzkoušíme
258258
$ git l
259259
@@ -280,6 +280,7 @@ Nyní se podíváme na stav commitů, jak jdou za sebou `git l`. Vidíme, že n
280280

281281
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.
282282

283+
#### Cherry-pick
283284
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ě):
284285

285286
```
@@ -301,6 +302,21 @@ Takže umíme:
301302
- cherry-picknout commit zpátky
302303

303304
Procvičit! Celé znovu!!
305+
**Úkoly**: Vše kontrolovat přes `git s` nebo `git l`!!!
306+
- vytvořit soubor `cvicime.md`
307+
- přidat soubor do stage pro commit
308+
- odebrat ze stage pro commit
309+
- smazat soubor
310+
- přidat soubor
311+
- přidat do stage pro commit
312+
- commit s message `pridali jsme soubor cvicime.md pro cviceni`
313+
- udělat změny v souboru
314+
- smazat změny přes git
315+
- udělat znovu změny
316+
- přidat změny do stage pro commit
317+
- commitnout změny s message `cvicebni zmeny v souboru cvicime.md`
318+
- smazat oba dva commity najednou
319+
- dostat přes Git je zpátky
304320

305321
```
306322
$ cd ..
@@ -338,11 +354,11 @@ $ git add ten-se-ma-jmenovat-jinak.js
338354
$ git commit --am
339355
```
340356

341-
**--am** nebo též **--amend** říká "tyhle změny přidej do předchozího commitu tj. nevytvářej nový"
357+
`--am` nebo též `--amend` říká "tyhle změny přidej do předchozího commitu" tj. nevytváří se nový commit, změny jsou jen přilepeny k aktálnímu.
342358

343-
**--no-edit** říká, že nechceme měnit původní commit message, ale chceme ponechat tu z předchozího commitu. Pokud bychom toto vynechali, tak by vyskočil VIM a to je zbytečná práce.
359+
`--no-edit` říká, že nechceme měnit původní commit message, ale chceme ponechat tu z předchozího commitu. Pokud bychom toto vynechali, tak by vyskočil VIM a to je zbytečná práce.
344360

345-
Pokud nepoužijeme `--no-edit` tak pomocí `git commit --am` můžeme jednoduše upravovat commit message posledního commitu.
361+
Pokud nepoužijeme `--no-edit` tak pomocí `git commit --am` můžeme jednoduše upravovat **commit message** posledního commitu.
346362

347363
Šup s tím do aliasu:
348364
```
@@ -404,7 +420,124 @@ Smazat již trackované soubory je snadné:
404420
$ git rm --cached < název souboru >
405421
```
406422

407-
Blbý je, pokud je tenhle soubor už commitnutej, to se pak musí z vyzobnout z commitu, který ho přidal - ukážeme si.
423+
Blbý je, pokud je tenhle soubor už commitnutej, to se pak musí z vyzobnout z commitu, který ho přidal - to umí `git reset --soft`, že?
408424

425+
## Branching
426+
Větvení je další esenciální featura Gitu.
427+
428+
Každý Commit má jenom jednoho předka, ale nikde není psáno, že jeden commit nemůže mít několik potomků. Commity se sdružují do stromové struktury:
429+
430+
[![GitBranch](https://www.drupal.org/files/repositorydiagram.png)](Branch)
431+
432+
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í.
433+
434+
### K čemu to je dobrý?
435+
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.
436+
437+
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.
438+
439+
### Jak na branchování
440+
Jednoduše se dá zjistit na jaké branch jsme teď + zobrazení všech větví:
441+
```
442+
$ git branch
443+
444+
// rychle udělat alias
445+
$ git config --global alias.b branch
446+
```
447+
A zobrazí se nám **master**.
448+
449+
**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`.
450+
451+
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.
452+
453+
#### Vytvoření vývojové větve
454+
Vytvořit **branch** - větev se dá mnoha způsoby.
455+
```
456+
// klasicky
457+
$ git branch english
458+
```
459+
Stalo se to, že jsme z rodičovské verze `master` vytvořili novou větev, která se jmenuje `english`.
460+
461+
`git checkout` se používá nejen pro smazání unstaged změn, ale taky k přepnutí branchí:
462+
```
463+
$ git checkout english
464+
$ git b
465+
```
466+
Ukáže se nám seznam branchí a naše aktuální, na kterou jsme se přepnul přes `git checkout`.
467+
468+
Tohle je ale zdlouhavý způsob. Sám `git branch` používám jenom k zobrazení větví. K vytváření větví používám:
469+
```
470+
// zpět na master
471+
$ git checkout master
472+
$ git b // jsme v masteru
473+
474+
// smazání větve
475+
$ git branch -D english
476+
477+
// vytvoření větve english a přepnutí do ní rovnou
478+
$ git checkout -b english
479+
$ git b // jsme v english větvi
480+
```
481+
No a co teď?
482+
483+
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.
484+
```
485+
$ touch english.md
486+
$ git add english.md
487+
$ git cm "add file in english on english branch"
488+
```
489+
Nyní, pokud se přepneme do masteru soubor `english.md` zmizí, protože je vedený pouze na větvi `english`.
490+
491+
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.
492+
493+
To je v pohodě. Ale horší budou jiné věci...
494+
495+
Nyní, pokud chceme ukázat větvení, tak se přepneme zpátky do masteru a uděláme commit:
496+
```
497+
$ git checkout master
498+
$ touch czech.md
499+
$ git add --all
500+
$ git cm "added file in czech on master branch"
501+
```
502+
Zkusíme příkaz `git l`, pokud nemáte nastavený stejně alias, napište:
503+
504+
```
505+
git log --graph --all --decorate --pretty=oneline --abbrev-commit
506+
```
507+
Voila - už nám rostou větvičky ze stromu a bude hůř!
508+
509+
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.
510+
511+
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`.
512+
513+
Takže se přeneme do `masteru` zase zapíšeme několik poznámek do `notes.md` a změnu commitneme.
514+
515+
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.
516+
517+
Proč?
518+
519+
odpověď se nachází v `git log` nebo v `git l`.
520+
521+
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.
522+
523+
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?
524+
525+
### Rebase
526+
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`.
527+
528+
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:
529+
```
530+
$ git rebase master
531+
```
532+
`gite přebázuj aktuální větev na větev master = posuň větev english tak, aby vycházela z nejaktuálnější commitu větve master`
533+
534+
no a teď:
535+
```
536+
$ git l
537+
```
538+
539+
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`.
540+
541+
UF!
409542

410543

0 commit comments

Comments
 (0)