Prvním krokem je stanovit, co je hlavní větev. Obvykle to je stabilní linie, do které se integrují hotové funkce. Z ní vždy odbočujete a do ní se vracíte. Nikdy necommitujte přímo do hlavní větve, pokud na ní pracuje více lidí. Druhé pravidlo zní: než začnete novou větev, aktualizujte si lokální kopii hlavní větve. Tím zajistíte, že odbočujete z nejnovějšího stavu, a snížíte riziko, že budete muset řešit konflikty, které už dávno vyřešil někdo jiný.

Nejčastější chyba začátečníka je ticho. Když narazí na problém, tři hodiny hledá řešení sám, aby nevypadal hloupě. Zkušený vývojář se zeptá po dvaceti minutách a mezitím sepíše, co zkusil. Druhá chyba je brát všechno osobně. Komentář k chybě v kódu není útok na tvoji osobu. Třetí chyba je učit se jen jeden nástroj. Jazyk se mění, principy zůstávají. Nauč se číst dokumentaci, psát testy a rozumět chybovým zprávám. To se počítá i za pět let.

Výběr vývojového prostředí pro Python nezačíná u vzhledu ani u počtu rozšíření. Začíná u otázky, kde a jak bude kód skutečně běžet. Pokud pracuješ na jednom projektu s jedním interpretem, vystačíš s čímkoli, co umí spustit skript a zastavit se na řádku s chybou. Jakmile ale přibude druhý projekt s jinou verzí knihoven, začne být klíčové, jestli prostředí rozumí virtuálním prostředím a umí mezi nimi přepínat bez restartu.

Nezapomínej na ladicí běh. Nastav breakpoint, spusť program a zkontroluj, jestli vidíš hodnoty proměnných v okamžiku zastavení. Některá prostředí vyžadují doplňkový konfigurační soubor, jiná fungují okamžitě. Pokud ladění vyžaduje ruční zápis konfigurace, je to přijatelné, ale jen když rozumíš každému řádku. Zkopírovaná konfigurace bez pochopení bývá častým zdrojem chyb, které se projeví až za běhu.

První praktický krok: zjisti, jestli prostředí pozná aktivní interpret. Otevři terminál, zadej python --version a pak totéž v integrovaném terminálu editoru. Často se čísla liší, protože editor sahá po systémovém Pythonu, zatímco ty pracuješ v projektovém. Řešení je nastavit cestu k interpretu přímo v konfiguraci projektu, ne globálně. Tím se vyhneš nejčastější chybě začátečníků: nainstalovaný balíček se nenačte, protože patří jinému interpretu.

Stavy, na které se zapomíná Největší rozdíl mezi prototypem a použitelnou aplikací jsou stavové obrazy. Vývojář často řeší jen ten šťastný případ: data dorazila, vše se vykreslilo. Ale co prázdný seznam? Co načítání? Co chyba sítě? Co neplatný vstup? Každá z těchto situací potřebuje vlastní obrazovku nebo alespoň text. Prázdný stav nemá být bílá plocha, ale krátká věta a výzva k akci. Chybová hláška nemá být „Error 500", ale co se pokazilo a co má uživatel udělat dál. Načítání delší než zlomek sekundy potřebuje indikaci, jinak uživatel klikne znovu.

Prvním krokem je rozhodnout, co vlastně verzovat. Pokud děláš statický web, patří do repozitáře zdrojové soubory: HTML, CSS, JavaScript, obrázky, konfigurace. Naopak složky jako node_modules, buildované soubory nebo lokální nastavení editoru tam nepatří. Ty se řeší pomocí souboru .gitignore, který říká, co má Git ignorovat. Bez něj ti během chvíle nabobtná historie o tisíce zbytečných souborů a orientace v commitech se změní v noční můru.

Poslední rada: vyber si prostředí, které zvládneš ovládat klávesnicí. Můžeš mít sebelepší doplňování, ale pokud kvůli každé operaci saháš po myši, přicházíš o čas i soustředění. Nauč se pět klávesových zkratek pro pohyb mezi soubory, hledání v projektu a spuštění testů. Teprve pak zvažuj rozšíření. Prostředí, které ti sedne, poznáš podle toho, že po týdnu používání přestaneš přemýšlet nad tím, jak je ovládat.

Poslední věc, na kterou se zapomíná, je záloha. Lokální repozitář je fajn, ale pokud ti odejde disk, historie je pryč. Proto se vyplatí mít vzdálený repozitář, kam budeš pravidelně odesílat změny. Není to o tom, komu data svěřuješ, ale o tom, že máš druhou kopii. Ať už zvolíš jakoukoli službu, princip je stejný: propojíš lokální repozitář s vzdáleným a po každé ucelené práci odešleš změny nahoru. Verzování se tak stane přirozenou součástí vývoje, ne otravnou povinností na konci dne.

Typická chyba začátečníků je, že commitují příliš velké změny najednou. Napíšou tři nové sekce, přepíšou styly a opraví chybu v JavaScriptu – a to všechno v jednom commitu s popisem „update". Za měsíc nebudeš vědět, co se změnilo a proč. Drž se pravidla, že jeden commit řeší jednu věc. Zpráva má být krátká a výstižná, například „oprava responzivního menu" nebo „přidání validace formuláře". Česky, anglicky, ale hlavně konzistentně.