|
| 1 | +Teoretické otázky |
| 2 | + |
| 3 | + 1. Proč je vhodné nastavit uživatelské jméno a e-mail hned po instalaci? |
| 4 | + - aby bylo dohledatelné, kdo udělal kterou změnu. Což je v týmovém projektu žádoucí |
| 5 | + 2. Jaký je rozdíl mezi pracovním adresářem, indexem (staging area) a repozitářem? |
| 6 | + pracovní adresář - místo na disku, kde pracuji se soubory (vytvářím, mažu, edituju...) |
| 7 | + index(staging area) - dočasné uložiště změn, které budu commitovat |
| 8 | + git add nazev souboru |
| 9 | + repozitář - místo, kde git ukládá historii změn |
| 10 | + Je to vnitřní databáze Gitu, kde se trvale ukládají commity a historie projektu. Git ukládá každý commit jako „snímek“ aktuálního stavu (snapshot). |
| 11 | +Tato databáze je ve skryté složce .git/ uvnitř projektu(uvniř adresáře projektu na disku, zakládá se git init. |
| 12 | + PRACOVNÍ ADRESÁŘ → (git add) → INDEX → (git commit) → REPOZITÁŘ |
| 13 | + |
| 14 | + 3. Co se děje při příkazu git add a co při git commit? |
| 15 | + git add - přídá změny do indexu(staging area), připravuji si změnu nebo soubor ke commitu |
| 16 | + git add soubor.txt - přidán jeden soubor |
| 17 | + git add . - přidá všechny změny |
| 18 | + !!git add neukládá změny do historie, jen je připraví |
| 19 | + git commit vezme změny ze staging area a uloží je do repozitáře jako nový commit |
| 20 | + git commit -m "Přidal jsem nový soubor" |
| 21 | +git uloží obraz těchto změn do své databáze(.git/) |
| 22 | + 4. Vysvětli, co je to commit hash a proč je důležitý. |
| 23 | + Unikátní označení revize(commitu), pomocí kterého se vždy bude dát dostat k této konkrétní verzi projektu. |
| 24 | +je to 40místný kód vygenerovaný pomocí SHA-1 hashovací funkce,jednoznačné identifikuje každou revizi (verzi). |
| 25 | + 5. Jak Git uchovává historii změn? Uveď rozdíl oproti klasickému ukládání souborů. |
| 26 | + git ukládá změny jako snapshoty(snímky) celého projektu v čase, neduplikuje obsah, ukládá pouze změny a nový commit odkazuje na předchozí commit a tím vzniká historie. Lze se vrátit ke každé předchozí verzi, komprimuje změny efektivně (neduplikuje) |
| 27 | + 6. Co znamená, že Git je „distribuovaný systém pro správu verzí“? |
| 28 | + Každý z vývojářů/uživatelů má u sebe kompletní plnohodnotnou verzi repozitáře projektu s celou historií a může na projektu pracovat nezávisle na připojení k nějakému centrálnímu serveru. |
| 29 | + 7. Proč je doporučeno používat větve místo práce přímo v hlavní větvi (main/master)? |
| 30 | +Je výhodné udržovat master/main ve funkční verzi a změny provádět ve vedlejší větvi a sloučit je do main až, když jsem spokojen.Díkz tomu může pracovat na různých úpravách paralelně více lidí a main zůstává stále funkční a stabilní, až je změna otestovaná, funkční, schválená, zmerguje se do main. Nebo se taky může od změny ustoupit a větev se pak jednoduše smaže. Main zůstává stále funkční. |
| 31 | + 8. Jaký je rozdíl mezi git merge a git rebase? Uveď příklad, kdy bys použil/a který. Co se stane s historií, pokud sloučíš větev pomocí merge? A co při rebase? Pozn.: Co je rebase jsme se na kurzu neučili, ale jde taky o způsob slučování větví, který je dobré znát. Zkus si o tom dohledat informace. |
| 32 | + Git merge používáme k začlenení úprav provedených ve větvích do main, při použití git merge se zachová historie včetně větví. |
| 33 | + Git rebase- při tomto použití se změny větvi zařadí za main, vzpadá to, jako kdyby vznikly z main.. historie je lineární.- nesmí se používat na veřejných větvích. |
| 34 | +9. Jaký je účel pull requestu a proč se používá? |
| 35 | +je to žádost o začlenění mnou provedených změn z mé kopie repozitáře y mé větve funkce do hlavního repozitáře autorů projektu. Umožňuje spolupráci více lidí na jednom projektu a do stabilní verze main projektu jsou tyto změny přidány až po schválení autory. |
| 36 | +10. Co znamená code review a jaký je jeho přínos? |
| 37 | +kodová kontrola, zpravidla během pull requestu, kolegové si mohou projít změnz řádek po řádku, mohou yanechat komentáře, návrhy, připomínky, zvyšuje kvalitu kódu a snižuje počet chyb. |
| 38 | +11. K čemu je soubor .gitignore ? |
| 39 | +je to speciální soubor, do kterého zapisujeme soubory nebo složky, které nemá Git sledovat (trackovat) a nemá je zahrnovat do commitů. |
| 40 | +repozitář zůstává čistý a přehledný, Git nesleduje stovky zbytečných souborů. |
| 41 | +12. Co se stane, pokud přidáš do .gitignore soubor, který už je ve verzovací historii? |
| 42 | +Git ho NEPŘESTANE sledovat automaticky. |
| 43 | +Přestože je uvedený v .gitignore, zůstává sledovaný, dokud ho ručně neodstraníš z indexu. |
| 44 | +13. Proč je vhodné ignorovat logy, dočasné soubory editorů nebo sestavení? |
| 45 | +Nejsou součástí zdrojového kódu, zbytečně by nafukovaly repozitář, dočasné soubory se čast mění. |
| 46 | +Logy - Velké, mění se, nikdo je nepotřebuje verzovat |
| 47 | +Soubory editorů - Osobní nastavení, nepatří do repozitáře |
| 48 | +Sestavení (build) - Vygenerované, dá se je znovu vytvořit |
| 49 | +Dočasné soubory- Nepodstatné pro projekt, vznikají automaticky |
| 50 | +14. Jak se zapisují vzory do .gitignore? Uveď příklady pro: |
| 51 | + ignorování všech .log souborů - *.log |
| 52 | + ignorování adresáře build - build/ |
| 53 | + ignoruje všechny složky build kdekoliv v projektu - **/build/ |
| 54 | + *.tmp - Ignoruje všechny dočasné .tmp soubory |
| 55 | + !important.log - NEignoruje soubor important.log (výjimka) |
| 56 | + |
0 commit comments