|
| 1 | +"1.Proč je vhodné nastavit uživatelské jméno a e-mail hned po instalaci? |
| 2 | +Protože Git ukládá do každého commitu informaci o autorovi. Pokud není jméno a e-mail nastaveno, commit nemusí být správně identifikovatelný, což komplikuje spolupráci. |
| 3 | + |
| 4 | +2. Jaký je rozdíl mezi pracovním adresářem, indexem (staging area) a repozitářem? |
| 5 | + |
| 6 | +Pracovní adresář – aktuální stav souborů na disku. |
| 7 | + |
| 8 | +Index (staging area) – příprava souborů, které budou zahrnuty do příštího commitu. |
| 9 | + |
| 10 | +Repozitář – databáze historie commitů a metadat uvnitř adresáře .git. |
| 11 | + |
| 12 | +3. Co se děje při příkazu git add a co při git commit? |
| 13 | + |
| 14 | +git add – přidá změny z pracovního adresáře do indexu. |
| 15 | + |
| 16 | +git commit – uloží změny z indexu do repozitáře jako nový commit. |
| 17 | + |
| 18 | +4. Vysvětli, co je to commit hash a proč je důležitý. |
| 19 | +Je to jedinečný identifikátor (SHA-1 nebo novější algoritmus), který jednoznačně určuje konkrétní commit. Díky němu lze přesně odkazovat na konkrétní stav projektu. |
| 20 | + |
| 21 | +5. Jak Git uchovává historii změn? Uveď rozdíl oproti klasickému ukládání souborů. |
| 22 | +Git ukládá rozdíly (snapshots) a propojuje commity grafovou strukturou. Na rozdíl od klasického ukládání souborů neukládá celé kopie projektu, ale efektivně sleduje změny. |
| 23 | + |
| 24 | +6. Co znamená, že Git je „distribuovaný systém pro správu verzí“? |
| 25 | +Každý uživatel má plnohodnotnou kopii celého repozitáře včetně historie. Není potřeba centrální server k práci. |
| 26 | + |
| 27 | +7. Proč je doporučeno používat větve místo práce přímo v hlavní větvi (main/master)? |
| 28 | +Větve umožňují vyvíjet nové funkce nebo opravy izolovaně, aniž by se rozbil stabilní kód v hlavní větvi. Zvyšují bezpečnost a přehlednost vývoje. |
| 29 | + |
| 30 | +8. Jaký je rozdíl mezi git merge a git rebase? Uveď příklad, kdy bys použil/a který. |
| 31 | + |
| 32 | +Merge – spojí dvě větve dohromady, zachová jejich historii. Vhodné při týmové práci, protože historie zůstane čitelná. |
| 33 | + |
| 34 | +Rebase – „přehraje“ commity jedné větve na konec druhé, čímž vytvoří lineární historii. Hodí se pro osobní větve před sdílením, aby byla historie přehlednější. |
| 35 | + |
| 36 | +Historie: |
| 37 | + |
| 38 | +Merge → vznikne nový merge commit, větve zůstanou zachované. |
| 39 | + |
| 40 | +Rebase → historie se přepíše, působí, jako by změny vznikly přímo po sobě. |
| 41 | + |
| 42 | +9. Jaký je účel pull requestu a proč se používá? |
| 43 | +Pull request slouží k navržení změn z jedné větve do jiné (např. feature → main). Umožňuje týmovou diskuzi, code review a kontrolu před začleněním kódu. |
| 44 | + |
| 45 | +10. Co znamená code review a jaký je jeho přínos? |
| 46 | +Je to proces, kdy kolegové kontrolují kód před sloučením. Přínos: zlepšení kvality, nalezení chyb, sdílení znalostí, dodržování standardů. |
| 47 | + |
| 48 | +11. K čemu je soubor .gitignore? |
| 49 | +Slouží k určení souborů a složek, které nemají být sledovány Gitem (např. logy, dočasné soubory, buildy). |
| 50 | + |
| 51 | +12. Co se stane, pokud přidáš do .gitignore soubor, který už je ve verzovací historii? |
| 52 | +Git ho bude dál sledovat, dokud ho z historie neodstraníš (git rm --cached). .gitignore funguje jen na nové (nesledované) soubory. |
| 53 | + |
| 54 | +13. Proč je vhodné ignorovat logy, dočasné soubory editorů nebo sestavení? |
| 55 | +Protože jsou generované automaticky, často se mění a nemají význam pro historii projektu. Zbytečně by znepřehledňovaly repozitář. |
| 56 | + |
| 57 | +14. Jak se zapisují vzory do .gitignore? Uveď příklady: |
| 58 | + |
| 59 | +Ignorování všech .log souborů: |
| 60 | + |
| 61 | +*.log |
| 62 | +Ignorování adresáře build: |
| 63 | + |
| 64 | +/build/" > myfile.txt |
0 commit comments