První commit: od návrhu k přijetí Než začnete psát kód, založte si vlastní větev (fork) a v ní vytvořte samostatnou větev pro vaši změnu. Postupujte podle pokynů v dokumentaci – pokud tam není řečeno nic jiného, držte se stylu kódu, který už v projektu existuje. Napište testy pro novou funkci a ověřte, že všechny stávající testy procházejí. Commitové zprávy pište stručně a výstižně – popište, co děláte a proč, ne kopírujte celou diskuzi z issue. Po odeslání pull requestu se připravte na to, že maintaineři mohou požadovat úpravy. To je normální součást procesu, neznamená to, že vaše práce je špatná.<br>
<br>
<br>
<br>
Když pracujete v týmu, naučte se pravidla pro konflikty. Ke konfliktu dojde, když dva lidé upraví stejný řádek. Řešení je jednoduché: otevřete soubor, najdete označené části a ručně rozhodnete, která verze zůstane. Nebojte se konfliktů – jsou běžné a jejich řešení se rychle naučíte. Důležité je neukládat konfliktní soubory „naslepo" a vždy po vyřešení spustit testy. Pro lepší přehlednost používejte větve pojmenované podle úkolu, např. „feature/prihlasovani" nebo „bugfix/oprava-menu". To usnadní orientaci i spolupráci.<br>
<br>
<br>
<br>
Na závěr si zvykněte na pravidelný rytmus: commit mějte malé, merge dělejte často, a před nahráním na vzdálený server si vždy stáhněte aktuální změny od kolegů. Tím minimalizujete konflikty a udržíte historii čitelnou. Verzování není jen o technice, ale o disciplíně. Začněte s jednoduchým projektem, zkoušejte větve a postupně si osvojte pokročilejší nástroje. Po pár týdnech zjistíte, že bez verzování už nikdy pracovat nechcete.<br>
<br>
<br>
<br>
Než začnete psát první řádky kódu, je dobré pochopit, co HTML a CSS vlastně dělají. HTML je kostra stránky – určuje strukturu, nadpisy, odstavce, obrázky a odkazy. CSS je pak styling – barvy, písma, mezery, rozmístění prvků. Bez CSS by stránka vypadala jako obyčejný text na bílém pozadí. Začněte tím, že si vytvoříte dva soubory: jeden s příponou .html a druhý s příponou .css. Do HTML souboru napište základní strukturu: doctype, html, head a body. Propojení CSS provedete pomocí odkazu v hlavičce.<br>
<br>
<br>
<br>
Ve větších projektech se vyplatí zavést pravidlo, že každá knihovna je verzovaná nezávisle na aplikaci, ale zároveň existuje centrální soubor, který definuje kompatibilní kombinace. Tento soubor může být jednoduchý textový dokument nebo strojově čitelný manifest. Důležité je, aby obsahoval matici testovaných verzí – tedy které verze knihoven spolu fungují a které ne. Tím se vyhnete situaci, kdy vývojář nasadí novou verzi knihovny A, aniž by věděl, že to rozbije knihovnu B. Automatizované testy by měly tuto matici pokrývat alespoň pro kritické cesty aplikace.<br>
<br>
<br>
<br>
Odhad času v agilním týmu je častou příčinou sporů, pokud se tým nesoustředí na rozložení práce mezi analytickou fázi a samotnou implementaci. Většina chyb vzniká tím, že se analýza podcení nebo naopak přecení a kódování pak nemá dostatečný prostor. Klíčové je rozdělit odhad na dvě samostatné části a každou z nich řídit podle konkrétního rizika, ne podle obecného procenta.<br>
<br>
<br>
<br>
Nejprve si vyberte projekt, který skutečně používáte, nebo který vás tematicky baví. Projděte si jeho dokumentaci, zvláště soubory s pokyny pro přispěvatele. Ty obvykle obsahují informace o tom, jak se staví projekt, jaké jsou konvence pro psaní kódu a jak probíhá review. Pokud takový soubor chybí, podívejte se na strukturu repozitáře a na to, jak vypadají poslední commity. Dobrým začátkem je hledat problémy označené jako vhodné pro začátečníky – obvykle bývají menší, dobře popsané a mají jasný rozsah.<br>
<br>
<br>
<br>
Typické chyby, které dělají začátečníci, jsou: zapomenutí koncového lomítka u prázdných elementů (např. ), chybné uzavírání značek, používání inline stylů místo CSS tříd, nebo absence responzivního designu. Pro responzivitu používejte media queries – v CSS definujte pravidla pro různé šířky obrazovky. Například pro mobilní zařízení pod 600 pixelů můžete změnit velikost písma nebo skrýt některé prvky. Také se vyhněte používání tabulek pro rozvržení – používejte flexbox nebo grid, což je moderní a jednodušší.<br>
<br>
<br>
<br>
Prohlížení historie změn je klíčové pro pochopení projektu. Příkaz git log zobrazí seznam commitů s jejich hashi, autory a daty. Pro rychlejší přehled použijte git log --oneline, který zobrazí jen krátký hash a popis. Pokud potřebujete porovnat změny mezi dvěma commity, použijte git diff. Často se stává, že si nejsme jistí, co jsme v daném souboru měnili – právě git diff ukáže konkrétní řádky, které jste přidali nebo smazali. Nezapomeňte, že diff neukazuje nově přidané soubory, které nejsou v repozitáři.
