Začněte s Flexboxem pro jednoduché komponenty, jako jsou navigační lišty, tlačítka nebo seznamy ikon. Použijte display: flex a nastavte justify-content: space-between, aby se prvky rovnoměrně rozmístily. Pozor ale na častou chybu: když necháte všechny položky flexboxu bez flex-wrap, na úzkém mobilu se vám obsah přetéká a vznikne vodorovné posouvání. Vždy přidejte flex-wrap: wrap a případně minimální šířku položek, aby se korektně zalamovaly.

Při testování IDE si všímejte, jak rychle se otevře a jak reaguje na psaní. Některá prostředí jsou náročná na paměť, což oceníte na výkonném počítači, ale na starším notebooku vás to bude brzdit. Typická chyba: stáhnete si nejpopulárnější nástroj, ale po pár týdnech zjistíte, že vám nevyhovuje jeho vzhled nebo náročnost konfigurace. Místo toho vyzkoušejte tři nebo čtyři různé možnosti a věnujte každé alespoň jeden den. Pracujte na reálném projektu, ne jen na ukázkové úloze, protože teprve tak odhalíte, co vám nástroj usnadňuje a co naopak komplikuje.

Na závěr si zkuste přečíst svou zprávu očima někoho, kdo projekt nezná. Pokud by mu dávala smysl a věděl by, proč byla změna provedena, máte vyhráno. A pokud si nejste jistí, podívejte se na historii svých posledních commitů – často uvidíte, co je třeba zlepšit. Psaní kvalitních zpráv je dovednost, která se dá trénovat, a odměnou je vám přehledná historie, která šetří čas při každé spolupráci.

Když uděláte chybu, nezoufejte. Příkaz git status vám ukáže, co se děje, a git log zobrazí historii commitů. Pokud potřebujete vrátit zpět změny v necommitnutém souboru, použijte git checkout — soubor. Pro vrácení posledního commitu slouží git revert – ale pozor, nevracejte se pomocí git reset, pokud si nejste jisti, protože to může smazat práci. Vždy si raději přečtěte dokumentaci.

Kde začít: automatizace jako první krok Nejprve si vyberte jeden malý projekt, který není kritický pro chod firmy. Může to být interní nástroj nebo nová služba. Na něm zaveďte automatizované sestavení, testy a nasazení do testovacího prostředí. K tomu budete potřebovat verzovací systém (například Git), CI server a skripty pro nasazení. Nebojte se začít s jednoduchými skripty, které spouštíte ručně – později je snadno zautomatizujete. Klíčové je, aby opakované činnosti byly popsány kódem a ne závisely na znalosti jednoho člověka.

Verzování kódu je pro každého programátora nezbytností. Git je nejrozšířenější nástroj, který vám umožní sledovat změny v projektech, vracet se k předchozím verzím a spolupracovat s týmem. Pokud s ním začínáte, nemusíte se bát – stačí pochopit pár základních principů a zvládnete první kroky.

Základní pracovní cyklus: add, commit, push Klíčem k úspěchu je pochopit tři kroky. Nejprve soubor upravíte, poté ho přidáte do tzv. staging area pomocí git add . (přidá všechny změněné soubory) a nakonec uložíte snímek pomocí git commit -m “Popis změny”. Zpráva by měla být krátká, ale výstižná – popisuje, co jste udělali. Tento cyklus opakujte při každé logické změně. Když pracujete s vzdáleným úložištěm (např. na serveru), odešlete své commity příkazem git push.

Když procházíte historii projektu, každá commit zpráva by měla odpovědět na dvě otázky: co se změnilo a proč. Většina vývojářů ale píše zprávy jako „oprava bugu” nebo „úpravy”. Takové popisy jsou k ničemu, protože neříkají, co přesně se dělo, a hlavně proč. Bez kontextu se po pár měsících vracíte k hádankám a musíte ručně procházet diff, abyste zjistili, co se vlastně stalo. Cílem není psát romány, ale dodat dostatek informací, aby se kdokoli v historii rychle zorientoval.

Dalším bodem je délka zprávy. Krátké shrnutí je povinné, ale podrobný popis by měl být maximálně pár odstavců. Pokud potřebujete vysvětlit více, je lepší rozdělit změny na menší commity. Nepište ale ani zprávy, které jsou jen shrnutím diffu – to je zbytečné. Místo toho se zaměřte na kontext: jaké problémy změna řeší, jaké jsou její vedlejší účinky, co by mohlo být překvapivé. Tím pomůžete kolegům i budoucímu sobě.

Jak strukturovat zprávu, aby dávala smysl Začněte krátkým shrnutím do padesáti znaků, které vystihuje podstatu změny. Například „Přidána validace e-mailu ve formuláři” je mnohem lepší než „oprava formuláře”. Po shrnutí následuje prázdný řádek a poté podrobnější popis. V něm vysvětlete, proč jste změnu provedli, jaký problém řeší, případně jaké alternativy jste zvažovali. Pokud změna souvisí s konkrétním úkolem nebo chybou, uveďte její identifikátor. Ale pozor – nepropadejte formalismu. Zpráva musí být čitelná pro člověka, ne pro stroj.