Dokumentace má být součástí vývoje, ne jednorázová akce na konci. Ideálně vzniká ze stejného zdroje, ze kterého se generuje i kód nebo testy. Když se změní implementace, změní se i dokumentace ve stejném commitu. Prakticky to znamená psát popisy přímo v anotacích nebo ve schématu, ze kterého se stránka s dokumentací sestaví. Tím zmizí rozdíl mezi tím, co je napsané, a tím, co server skutečně dělá.

Autentizaci a autorizaci popište zvlášť, protože se dotýkají všech volání. Napište, jak se token získává, kam se vkládá, jak dlouho platí a co se stane po jeho vypršení. Stejně důležité je uvést, která role smí volat který endpoint. Bez toho vznikají situace, kdy frontend zobrazí tlačítko, které backend stejně odmítne. Předejdete tomu, když se na pravidlech dohodnete dřív, než se začne psát kód.

Pro návrat k dřívější verzi slouží git checkout nebo novější git switch. Můžeš si tak zobrazit starší stav souboru, aniž bys o cokoli přišel. Důležité je vědět, že rozpracované změny se při přepnutí mohou ztratit, pokud nejsou uložené. Proto je ukládej průběžně a ne až na konci dne. Zvyk ukládat malé změny často je to, co dělá Git užitečným. Velké a vzácné ukládání z něj dělá jen složitější zálohu.

Paralelizace zrychluje, ale jen do určité míry. Pokud testy sdílejí stav, paralelní běh způsobí náhodná selhání, kterým se říká flaky tests. Nejprve zjistěte, které testy jsou na sobě nezávislé, a ty pouštějte souběžně. Ostatní nechte v jedné frontě. Sledujte dobu běhu a úspěšnost. Pokud některý test selhává v jednom z deseti běhů, opravte ho nebo dočasně vypněte. Flaky testy jsou horší než žádné testy, protože ničí důvěru v pipeline.

Pro kontrolu stavu slouží git status, který ukáže, co je upravené a co čeká na uložení. git log zobrazí seznam uložených bodů od nejnovějšího. Pokud se spleteš ve zprávě k poslednímu uložení, použij git commit --amend. Tím ale měníš už zapsanou historii — u uložení, která už někdo jiný stáhl, to nedělej, způsobí to zmatky. Stejně tak git reset --hard smaže neuložené změny bez varování. Než ho spustíš, ujisti se, že opravdu nechceš nic zachovat.

První věc, kterou je potřeba udělat, je nastavit jméno a e-mail. Git je připisuje ke každému uloženému bodu, takže pokud to neuděláš, nebude vědět, komu změnu připsat. Příkazy git config --global user.name a git config --global user.email stačí spustit jednou pro celý počítač. Pak už jen ve složce s projektem spustíš git init. Tím vznikne skrytá složka, ve které Git drží celou historii. Tuhle složku nikdy nemaž ručně — přišel bys o všechny uložené změny.

Pipeline postavte tak, aby selhala rychle. První fáze má trvat do dvou minut: instalace závislostí, lint a unit testy. Teprve potom spouštějte integrační a end-to-end testy. Pokud první fáze selže, další se vůbec nespouštějí. Tím ušetříte výpočetní kapacitu i nervy. Do logu vždy vypište, který test selhal a proč. Bez čitelného výstupu budete trávit hodiny hledáním příčiny.

Git není jen nástroj pro programátory v týmech. Pokud potřebuješ vrátit soubor do stavu před dvěma hodinami, porovnat dvě verze textu nebo si jen dělat poznámky k tomu, co se změnilo, Git ti to umožní. Základní myšlenka je jednoduchá: každá uložená změna je samostatný bod v historii, ke kterému se můžeš kdykoli vrátit. Bez pochopení tohoto principu skončíš v tom, že budeš mít na disku deset souborů s názvy jako „projekt_final_2_opravdu_final".

Izolujte prostředí a data Testy, které běží proti sdílené databázi, dřív nebo později selžou. Každý běh potřebuje vlastní instanci databáze nebo alespoň vlastní schéma. Použijte kontejnery, které se po dokončení testů zničí. Data pro testy vytvářejte skriptem, ne ručně. Pokud test závisí na datech, která někdo předtím vložil, není to test, ale loterie. Stejně tak pozor na časová pásma a náhodné hodnoty – test musí být deterministický.

Pracovní postup, který se nevyplácí přeskočit Základní cyklus má tři kroky: upravíš soubory, přidáš je do připravované změny a uložíš ji. Příkaz git add označí, co má být součástí příštího uložení, a git commit -m "popis" změnu zapíše do historie. Zpráva by měla říkat, co se změnilo a proč, ne jen „oprava". Na začátku je snadné zapomenout na git add a divit se, že se uložilo jen půlku práce. Druhá častá chyba je ukládat příliš velké změny najednou. Když se pak něco pokazí, těžko hledáš, která část to způsobila.

Nastavte notifikace tak, aby nikoho nezahlcovaly. Informace o selhání patří do kanálu, který tým skutečně čte. Neposílejte e-mail při každém neúspěchu, jinak si všichni vypnou upozornění. Důležité je také udržovat závislosti aktuální. Zastaralé knihovny způsobují selhání, která vypadají jako chyba v testech. Jednou za čas projděte pipeline a odstraňte testy, které už nic neověřují. Automatizace není jednorázový úkol, ale pravidelná údržba.