SheldonHowland2: Die Seite wurde neu angelegt: „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ě synchronizo…“

2026-08-21T18:38:02Z

Die Seite wurde neu angelegt: „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ě synchronizo…“

Neue Seite

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é.

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