Git bez zbytečných chyb: co pokazí i zkušené uživatele

Větve, rebase a past, která maže práci Větve nejsou kopie projektu, jen pohyblivé ukazatele na commity, takže jejich vytvoření je levné a rychlé. Příkaz git switch -c nazev-vetve založí novou větev a hned na ni přepne. Na hlavní větvi nechte jen to, co je ověřené, a experimenty dělejte jinde. Pozor na git switch s neuloženými změnami: Git vás sice většinou zastaví, ale při přepnutí s konfliktem můžete o rozpracovanou práci přijít. Před každým přepnutím věty zkontrolujte stav přes git status a hotové změny commitněte, nebo je odložte pomocí git stash.

Pozor také na doplňování kódu a na to, jak prostředí rozumí typům. Některá prostředí nabízejí našeptávání jen podle názvů, jiná skutečně analyzují kód. Rozdíl poznáš ve chvíli, kdy pracuješ s knihovnou, kterou dobře neznáš. Vyzkoušej to na jedné funkci s více parametry a sleduj, zda ti prostředí ukáže jejich názvy a typy.

Základní cyklus má tři kroky a plete se pořád dokola. git status ukáže, co se změnilo. git add soubor přesune změnu do přípravy (staging). git commit -m "popis" ji uloží jako bod v historii. Kdo vynechá git add, diví se, že commit je prázdný. Kdo naopak přidá omylem celý adresář přes git add ., dostane do historie i to, co tam nechce. Zpráva commitu nemá být „oprava" nebo „změny" — za měsíc nebudeš vědět, co se opravovalo. Piš krátce, ale konkrétně: „oprava dělení nulou v exportu".

Základ je jednoduchý: nainstalujte TypeScript přes správce balíčků a spusťte překlad. Vznikne soubor tsconfig.json, který určuje, jak přísně se má kontrola chovat. První praktický krok je zapnout „strict" na true. Zní to nepříjemně, protože vás to donutí řešit null a undefined, ale právě tam vzniká většina chyb za běhu. Druhý krok je nastavit „noImplicitAny" na true, aby se každé neuvedené typu nebralo jako „any". Právě „any" je nejčastější past: vypne kontrolu a TypeScript se změní v JavaScript s extra kroky.

Rebase umí vyčistit historii, ale přepisuje commity. Nikdy nedělejte rebase větve, kterou už někdo jiný stáhl a postavil na ní svou práci. Stejné pravidlo platí pro git push --force. Pokud už musíte historii přepsat na sdílené větvi, použijte --force-with-lease, které odmítne push v případě, že na serveru mezitím přibyly cizí commity. Sloučení přes git merge naopak nic nemaže, jen přidá nový commit se dvěma rodiči, a je proto bezpečnější volbou pro týmovou spolupráci.

Většina týmů se zasekne na tom, jestli pracovat s dlouho žijícími větvemi, nebo commitovat rovnou do hlavní linie. Rozdíl není v nástroji, ale byt v paneláku tom, jak rychle dokážete dostat změnu k ostatním a jak drahé je vrátit ji zpět. Trunk-based vývoj znamená, že každý den mergujete do main; feature branch znamená, že změna žije odděleně, dokud není hotová. Ani jedno není univerzálně správné.

Než cokoli nainstaluješ, napiš si na papír tři věci: jestli budeš psát hlavně skripty, nebo větší aplikace; jestli potřebuješ ladit krok za krokem; a jestli chceš spouštět buňky s grafy přímo v prostředí. Podle toho se rozhoduje, zda ti stačí lehký editor s doplňky, nebo potřebuješ plnohodnotné vývojové prostředí s integrovaným terminálem, debuggerem a správou virtuálních prostředí.

Pull requesty držte malé. Ideálně do 400 změněných řádků, jinak recenzent ztrácí pozornost a přehlédne chyby. Do popisu napište, co se mění a proč, ne jak. Recenzent potřebuje vědět, jaký problém to řeší, ne jak jste to napsali. Nikdy neschvalujte vlastní změny a nikdy nemergujte bez alespoň jednoho schválení od někoho jiného. Pokud na review nikdo nereaguje do jednoho pracovního dne, ozvěte se přímo — nečekejte.

Začněte tím, že si tým rozdělí práci na malé celky. Pokud větev žije déle než dva dny, rozpadá se na konflikty a ztracený kontext. Praktické pravidlo: jedna větev = jedna logická změna, kterou lze popsat jednou větou. Když popis potřebuje „a zároveň", rozdělte ji. Větve pojmenovávejte krátce a konkrétně, například oprava-prihlaseni nebo platebni-formular. Vyhněte se jménům jako vetev1, test nebo nova-verze.

Poslední věc, která rozhoduje o výsledku, je tón. Zpětná vazba nemá být obhajoba ani hodnocení člověka. Když někdo řekne, že něco nefunguje, není to útok. Facilitátor to musí říct nahlas, jinak se lidé začnou bránit a diskuze se změní v hádku o vině. Struktura drží emoce na uzdě jen do chvíle, kdy ji někdo začne používat jako zbraň. Proto je lepší mluvit o procesech a rozhodnutích než o lidech a jejich vlastnostech.

Nakonec si dej pozor na výkon u velkých projektů. Indexování tisíců prostředí zpomalit tak, že každé uložení trvá několik sekund. Pokud se to stane, vyluč z indexování složky s daty, virtuálními prostředími a build výstupy. A hlavně: vyber si jedno prostředí a používej ho alespoň měsíc. Přeskakování mezi editory je nejspolehlivější způsob, jak se nenaučit žádný pořádně.