Verzování kódu při práci na více feature větvích

Zároveň buďte připraveni na odmítnutí. Většina lidí dostane nabídku až po pěti až deseti pohovorech. Každé „ne" berte jako informaci – zeptejte se na důvody a vraťte se k tomu, co se můžete naučit. Klidně si dejte pauzu a pak pošlete další přihlášku. Nezapomínejte, že trh s IT se neustále mění, takže kdo vydrží a soustavně se zlepšuje, ten si první práci najde dřív, než čeká.

Jak správně synchronizovat větve Když potřebujete do své feature větve dostat změny z hlavní větve, nepoužívejte merge, ale rebase. Rebase přehraje vaše commity na nový základ a vytvoří lineární historii. To usnadňuje pozdější code review a snižuje riziko konfliktů. Postup je jednoduchý: přepnete se na hlavní větev, pullnete změny, přepnete se zpět na svou větev a provedete rebase. Při rebase se mohou objevit konflikty, které je nutné vyřešit. To je normální, ale pokud je to časté, znamená to, že se vaše větve příliš odchýlily.

Commit a kontrola historie Když máte soubory připravené, vytvořte commit pomocí git commit -m "popis změn". Zpráva by měla být krátká a vystihovat, co jste změnili – to se vám bude hodit při procházení historie. Pro zobrazení seznamu commitů použijte git log. Uvidíte hash (identifikátor), autora, datum a zprávu. Užitečný je také příkaz git status, který ukazuje, které soubory jsou změněné a které ještě nebyly přidány. Pokud omylem provedete commit s chybou, můžete jej opravit příkazem git commit --amend, který upraví poslední commit.

Jak převést návrh do kódu bez ztráty kvality Začněte vždy rozborem layoutu. Vytvořte si z návrhu jednoduchou kostru – rozdělte stránku na hlavní sekce, určete, které prvky jsou opakovatelné, a definujte vzdálenosti. Vyhněte se časté chybě, kdy začnete stylovat jednotlivé komponenty izolovaně a zapomenete na kontext. Používejte proměnné pro barvy, mezery a typografii. Pokud návrh obsahuje odstín, který se v paletě neopakuje, nebojte se designéra zeptat, zda je to záměr. Drobné odchylky v barvách nebo rádcích často vedou k nekonzistentnímu vzhledu.

Doporučuji také pravidelně porovnávat odhady se skutečností. Po dokončení úkolu si zapište, kolik času reálně zabral, a toto číslo porovnejte s odhadem. Po pár projektech získáte vlastní historická data, která vám umožní kalibrovat budoucí odhady. Pokud máte tendenci podhodnocovat, zvyšte odhad o koeficient (např. 1,5). Tento koeficient si ale musíte odvodit sami – je unikátní pro každý tým a typ práce.

Nejdůležitější je mít funkční portfolio. Místo pěti rozpracovaných projektů raději tři hotové, které běží, mají čistý kód a jsou zdokumentované. Publikujte je na veřejném repozitáři a připojte krátký popis, jakou jste řešili výzvu a co jste se naučili. Personalisti i techničtí lídři si všímají toho, jestli umíte dotáhnout práci do konce. Chyba je posílat životopis bez odkazů nebo s odkazy na nefunkční stránky.

Dalším důležitým aspektem je responzivita. Návrhy obvykle přicházejí v jedné velikosti, nejčastěji pro desktop. Vaším úkolem je rozhodnout, jak se layout přizpůsobí menším displejům. Při breakpointech se zaměřte na obsah – pokud se text na šířku nevejde, zalomte ho, ne jej zmenšujte. Mějte na paměti, že uživatelé na mobilu neklikají myší, ale prstem, takže minimální velikost tlačítek a odstupů musí být větší než na desktopu. Testujte na skutečných zařízeních, ne jen v devtools.

Git je nástroj, který sleduje změny v souborech a umožňuje vám vracet se k předchozím verzím. Pro začátečníka může být matoucí, ale stačí pochopit pár základních příkazů a workflow. Nejdůležitější je nejprve si Git nainstalovat a nastavit si uživatelské jméno a e-mail, protože bez nich nebudete moci vytvářet commity. Toto nastavení provedete příkazy git config --global user.name "vaše jméno" a git config --global user.email "vas@email.cz".

Prvním krokem je pochopení rozdílu mezi UI a UX. UI (User Interface) se týká vizuální stránky – barvy, typografie, mezery, ikony. UX (User Experience) pak zahrnuje celkový pocit z používání produktu, logiku toku obrazovkami a srozumitelnost interakcí. Jako vývojář byste měli vnímat obojí. Například místo abyste jen naprogramovali tlačítko, přemýšlejte, zda je jeho umístění očekávatelné a zda je jeho velikost dostatečná pro kliknutí prstem na mobilu. Tím předcházíte frustraci uživatelů a zbytečným bug reportům.

Prakticky to znamená, že před vytvořením nové větve si vždy aktualizujete hlavní větev a z ní vytvoříte větev novou. Pokud pracujete na více úkolech najednou, vytvořte si pro každý samostatnou větev. Nikdy nepracujte na dvou úkolech v jedné větvi, i když se zdají být podobné. Často se stává, že jeden úkol je hotový dřív a vy ho chcete nasadit, ale druhý ještě není dokončený. V tu chvíli je oddělení větví klíčové.