Druhý krok je větev. Pracujte vždy na nové větvi, ne přímo v hlavní. Vytvoříte ji příkazem git checkout -b nazev-vetve. Po dokončení práce větev odešlete do vzdáleného repozitáře a vytvořte požadavek na sloučení. Tím získáte možnost revize kódu a zároveň se hlavní větev nerozbije nehotovou změnou. Pokud jste zvyklí pracovat sami, i tak větev používejte – usnadní vám to návrat k předchozímu stavu, když se něco pokazí.

Nakonec si nastavte pravidla pro budoucnost. Každý nový soubor by měl mít jasnou licenci a původ. Při převzetí kódu od klienta si vždy nejdřív ověřte, zda smíte dílo používat, upravovat a dál šířit. Rozdíl mezi vlastní licencí a licencí klienta rozhoduje o tom, zda projekt převezmete bezpečně, nebo si přinesete problém, který se vrátí při dalším vydání.

Rozložení stránky dnes stojí na dvou technikách: flexbox pro řazení prvků v jednom směru a grid pro mřížku ve dvou směrech. Obojí zvládne většinu běžných úloh. Na co si dát pozor: nastavení šířky a výšky bez ohledu na obsah vede k přetékání. Obrázky potřebují maximální šířku a automatickou výšku, aby se vešly do sloupce. Mezery se dělají pomocí vlastností pro odsazení, ne prázdnými odstavci. Písmo se nastavuje v relativních jednotkách, aby se stránka přizpůsobila i zvětšení v prohlížeči.

Na závěr si nastavte pravidelný rytmus. Commitujte po každé dokončené drobnosti, ne jednou za týden. Před odchodem z práce odešlete větev na vzdálený server. Alespoň jednou za čas si ověřte, že umíte projekt naklonovat z repozitáře a spustit od nuly. Právě tehdy zjistíte, že jste zapomněli nějakou závislost nebo konfiguraci. Verzování není jednorázový úkol, ale návyk, který vám vrátí klid ve chvíli, kdy potřebujete dohledat, co se v kódu změnilo a proč.

Verzování kódu není volitelný doplněk, ale základní návyk. Pokud začnete příliš pozdě, první ztráta souboru nebo nechtěná změna v produkci vás to naučí rychle. Začít lze během několika minut a nepotřebujete k tomu žádné složité nástroje. Stačí nainstalovat Git, otevřít terminál ve složce projektu a spustit příkaz git init. Tím vznikne skrytá složka, která si pamatuje veškerou historii. Poté přidejte soubory příkazem git add . a uložte první stav příkazem git commit -m "první commit".

Typická chyba začátečníků je obalování všeho do prvku div. Ten sám o sobě nic neznamená. Nahradit se dá prvky jako header, nav, main, article, section nebo footer, které prohlížeči i vyhledávači řeknou, co která část znamená. Výsledkem je čitelnější kód a menší množství zbytečných obalů. Totéž platí pro tabulky: slouží k datům, ne k rozvržení stránky.

Pište commity malé a srozumitelné. Jeden commit by měl řešit jednu věc. Zprávy typu „oprava" nebo „změny" vám za měsíc nic neřeknou. Místo toho popište, co se změnilo a proč, například „oprava validace e-mailu ve formuláři". Pokud potřebujete více souborů upravit najednou, rozdělte práci do několika commitů. Menší commity se snadněji vracejí zpět a méně často způsobují konflikty při slučování.

Jakmile máte historii, naučte se vracet změny. Příkaz git log --oneline zobrazí přehled commitů. Pomocí git revert bezpečně vrátíte konkrétní commit, aniž byste mazali ostatní. Pokud chcete pouze odložit neuložené změny, použijte git stash. Vyhněte se příkazu git reset --hard, dokud přesně nevíte, co dělá – nevratně smaže neuloženou práci. Stejně opatrně zacházejte s přepisováním historie na sdílené větvi.

Nakonec si nastav, co se stane při selhání. Test, který nikdo nečte, je dražší než žádný test. Urči, kdo se na výsledek podívá a jak rychle. Opakovaně padající test buď oprav, nebo smaž – neignoruj ho. A hlavně: testy piš ve stejném jazyce a stylem jako zbytek kódu, jinak se v nich za měsíc nikdo nevyzná.

Než uděláte první commit, ošetřete citlivá data Nejčastější chyba začátečníků je, že do repozitáře pošlou konfigurační soubory s hesly, přístupovými klíči nebo celé složky s závislostmi. Vytvořte soubor .gitignore ještě před prvním přidáním souborů. Uveďte v něm například node_modules/, .env, vendor/, dist/ nebo *.log. Pokud už jste citlivá data omylem uložili, smazání souboru v dalším commitu nestačí – zůstanou v historii. Řešením je historie přepsat nebo klíče okamžitě zneplatnit. Prevence je zde výrazně jednodušší než následná oprava.

Portfolio rozhoduje, ne počet certifikát

Rozlišujte dvě situace. Buď kód vytvořil klient nebo jeho dodavatel a klient vám ho předává, nebo jde o open source, který má vlastní podmínky. V prvním případě potřebujete od klienta jasné prohlášení o právech a o tom, že je oprávněn vám je poskytnout. Ve druhém případě se musíte držet licence konkrétní komponenty. Některé licence vyžadují zveřejnění odvozeného díla, jiné jen uvedení autora. Záměna těchto dvou režimů je typická chyba při přebírání projektů.