Nezapomínejte na pravidelnou práci se vzdáleným úložištěm. Stačí jeden příkaz git push omylem zadat do špatné větve, a váš experiment se objeví na serveru. Před každým posláním změn zkontrolujte, na které větvi jste, pomocí git branch. A pokud si nejste jistí, použijte git pull –rebase místo klasického pull, tím se vyhnete zbytečným merge commitům, které znepřehledňují historii.

Nakonec se vyhněte pokušení psát testy až po dokončení velké části aplikace. Testujte průběžně, ideálně po každé malé změně. Tím získáte okamžitou zpětnou vazbu a vyhnete se hromadění chyb. Pamatujte, že test není nástroj pro formální splnění úkolu, ale jistota, že vaše kód dělá to, co má. Čím dříve si tento návyk osvojíte, tím méně času strávíte opravováním překvapivých problémů ve výrobě.

Začněte tím, že si osvojíte tři základní stavy souborů: upravený, připravený k zapsání a zapsaný. Git o vašich souborech ví jen to, co mu řeknete. Pokud upravíte soubor a rovnou uděláte commit, bez příkazu k přidání do indexu se změna neprojeví. Typická chyba začátečníka je spustit git commit -m “oprava” a čekat, že se uloží vše. Přitom commit obsahuje jen změny, které jsou v indexu. Vždy proto kontrolujte git status před tím, než něco zapíšete.

Dalším častým problémem je špatné sloučení větví. Když spojujete větev s hlavní linií, Git může hlásit konflikt. V tu chvíli se nezoufejte, soubory s konfliktem jsou označeny v textu značkami <<<<<>>>>>. Musíte ručně rozhodnout, která verze kódu zůstane. Často se stává, že nováček v panice smaže všechno a commitne prázdný soubor. Před vyřešením konfliktu si vždy zálohujte obsah obou verzí do dočasného souboru.

Základem je rozdělit si práci na menší celky a každý z nich řešit ve vlastní větvi. Před začátkem práce si vždy vytvořte větev z aktuálního stavu hlavní větve. Používejte výstižné názvy, které popisují úkol, třeba ‘oprava-prihlasovani’ nebo ‘pridani-filtru’. Hlavní větev udržujte stabilní – nikdy do ní necommitěte přímo, pokud nepíšete jen drobnou opravu dokumentace. Tím zajistíte, že hlavní větev je vždy ve stavu, který lze nasadit.

Jak se vrátit zpět, aniž byste si ublížili Největší strach začátečníků je, že něco změní a nebudou umět to vrátit. Git má pro tento případ dva klíčové příkazy: git reset a git revert. První slouží k vrácení posledního commitu, ale pozor, pokud jste změny už poslali na vzdálený server, reset způsobí konflikt s kolegy. Bezpečnější je revert, který vytvoří nový commit, jenž předchozí změny zruší. Tím se historie větve nemění a nikdo nepřijde o práci. Naučte se používat revert, než začnete experimentovat s resetem.

Jak začít s prvním testem bez zbytečných komplikací Nejprve si připravte prostředí. Vyberte si testovací framework, který odpovídá jazyku vašeho projektu. V Javě to bývá JUnit, v C# xUnit nebo NUnit, v Pythonu pytest. Ujistěte se, že máte v projektu správně nastavenou strukturu — testy patří do samostatné složky, oddělené od produkčního kódu. Vytvořte jednoduchý test, který ověří, že se metoda chová podle očekávání pro běžný vstup. Nepoužívejte žádné závislosti na databázi, síti ani jiných službách — test musí být rychlý a izolovaný.

Další častý problém je spoléhání na pořadí testů. Každý test musí být nezávislý — neměl by záviset na tom, jaký test běžel před ním. Pokud testy potřebují společná data, vytvořte je v metodě setUp, případně použijte pomocné funkce. Vyhněte se sdílení stavu mezi testy, protože to vede k nepředvídatelným výsledkům a ztěžuje hledání chyb. Když test napíšete, spusťte ho a ověřte, že skutečně selže, když je kód špatně. To je základní kontrola, že test dává smysl.

Po odeslání buďte trpěliví. Správci mají často hodně práce a odpověď nemusí přijít hned. Pokud do dvou týdnů nikdo nereaguje, můžete jemně připomenout v komentáři, ale nevyžadujte odpověď okamžitě. Běžná chyba je, že přispěvatel vezme kritiku osobně. Recenze není útok, ale snaha o kvalitu. Pokud vám někdo navrhne změny, poděkujte, zapracujte je a jasně napište, co jste upravili. Tím ukážete, že umíte spolupracovat.

Nezapomeňte na okrajové případy. První test obvykle pokrývá hlavní scénář, ale kvalitní test by měl zahrnovat i prázdné hodnoty, nulové vstupy nebo maximální velikosti. Není nutné pokrýt hned všechny, ale alespoň jeden okrajový případ vám pomůže odhalit skryté problémy. Pište testy čitelně — název testu by měl popisovat chování, které ověřuje, ne jen číslo metody. Takový přístup usnadní údržbu, až se ke kódu vrátíte za několik týdnů.