Jak začít s Gitem a neztratit se v historii změn

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.

Prohlížení historie změn je klíčové pro pochopení projektu. Příkaz git log zobrazí seznam commitů s jejich hashi, autory a daty. Pro rychlejší přehled použijte git log --oneline, který zobrazí jen krátký hash a popis. Pokud potřebujete porovnat změny mezi dvěma commity, použijte git diff. Často se stává, že si nejsme jistí, co jsme v daném souboru měnili – právě git diff ukáže konkrétní řádky, které jste přidali nebo smazali. Nezapomeňte, že diff neukazuje nově přidané soubory, které nejsou v repozitáři.

Základní cyklus práce s Gitem vypadá takto: provedete změny, označíte je jako připravené a potvrdíte je. Nejprve si zkontrolujte stav pomocí git status. Poté přidejte soubory do tzv. staging area příkazem git add . (všechny) nebo git add název_souboru (jen vybrané). Následně změny uložíte pomocí git commit -m "Popis změny". Každý commit by měl mít stručný a výstižný popis, který říká, co jste upravili a proč. Vyhněte se hromadným commitům typu "opravy" – později se v nich nevyznáte.

Základní princip pytestu je jednoduchý: píšete funkce, které začínají slovem test_, a uvnitř nich používáte příkazy assert. Pytest sám najde všechny soubory a funkce podle konvence pojmenování. Nemusíte nic registrovat ani dědit z nějaké třídy. Stačí mít soubor s názvem třeba test_math.py a v něm funkci test_add(). Když spustíte pytest v adresáři projektu, projde všechny soubory, které odpovídají vzoru test_*.py nebo *_test.py, a spustí všechny funkce test_*.

Po výběru prostředí se vyplatí investovat čas do základního nastavení. Nejdůležitější je správně nastavit interpret Pythonu: pokud používáte virtuální prostředí, ujistěte se, že IDE používá ten správný. Mnoho začátečníků dělá chybu, že spouští kód s globální instalací a poté řeší problémy s chybějícími balíčky, přestože je v projektu nainstalovaný správně. Dále si zjistěte klávesové zkratky pro spuštění souboru, přepínání mezi editorem a terminálem a pro komentování bloků kódu – ušetří vám to hodně času.

První krok spočívá v zavedení sémantického verzování pro každou knihovnu zvlášť. Formát tři čísla (hlavní, vedlejší, oprava) funguje dobře, ale musí být striktně dodržován. Hlavní číslo zvyšujte pouze při nekompatibilních změnách API, vedlejší při přidání funkce zpětně kompatibilním způsobem a opravné při opravě chyby. Důležité je, aby se tyto změny promítaly i do závislostí. Pokud knihovna A změní hlavní verzi, knihovna B, která ji používá, musí ve svém manifestu explicitně uvést nový rozsah povolených verzí. Bez toho vznikne chaotický stav, kdy různé části projektu používají nekompatibilní kombinace.

Častou chybou je psát zprávy v minulém čase, jako byste popisovali hotovou věc. Lepší je použít rozkazovací způsob nebo přítomný čas, protože to odpovídá tomu, co commit dělá, když je aplikován. Například „Přidej testy pro přihlášení" je jasné a akční. Vyhněte se také vágním slovům jako „úpravy", „oprava" nebo „refaktoring" – pokud neřeknou, co konkrétně je upraveno, opraveno nebo refaktorováno. Vždy doplňte, co je předmětem změny, ať už jde o soubor, funkci nebo chování.

Automatizace kontroly kompatibility místo ručního dohledu Ruční sledování verzí u více knihoven je neudržitelné, proto je nutné zapojit automatizované nástroje. Nejde o žádný konkrétní software, ale o princip: do CI (průběžné integrace) přidejte krok, který ověří, zda všechny deklarované závislosti existují a zda jejich verze odpovídají definovanému rozsahu. Tato kontrola by měla běžet při každém commitu a při každém vydání. Dále si vytvořte skript, který generuje zámek verzí (lockfile) pro celý projekt. Tento zámek zachytí přesné verze všech knihoven, které se aktuálně používají, a to včetně tranzitivních závislostí. Bez takového zámku se může stát, že vývojář na svém počítači pracuje s jinou kombinací než produkce, a to vede k nepředvídatelným chybám.

Jak psát testy, které dávají smysl Nejdůležitější je testovat chování, ne implementaci. Zaměřte se na to, co funkce dělá, ne na to, jak to dělá. Například místo testování, že funkce volá určitou metodu, ověřte, že vrací očekávaný výsledek pro daný vstup. Také je dobré testovat okrajové případy: prázdný seznam, nulu, záporná čísla, prázdný řetězec. Typická chyba začátečníků je testovat jen hlavní cestu, takže pak testy neodhalí chyby, které se objeví při neobvyklých vstupech.