Ještě než začneš psát kód, udělej dvě věci. Aktualizuj si main a novou větev vytvoř z něj, ne z větve, kterou máš otevřenou. Pojmenuj ji tak, aby z názvu bylo poznat, co řeší — třeba oprava-prihlaseni nebo filtr-faktur. Vyhni se názvům typu test, oprava nebo muj-ukol: za týden nikdo netuší, co v nich je. Větev drž krátce, ideálně na jeden problém. Dlouhá větev znamená mnoho konfliktů a hlavně nejistotu, jestli se ještě vůbec dá sloučit.

Při odhadu analytiky se ptejte na konkrétní věci: Kolik lidí musíme vyslechnout? Existuje už nějaká dokumentace? Jak moc se liší stávající systémy? Kolik variant scénářů musíme pokrýt? Kdo bude schvalovat výstup? Každá z těchto otázek může odhad posunout o dny. Typická chyba je odhadnout analytiku jako „půl dne na schůzku", i když schůzka je jen začátek a skutečná práce přichází po ní.

U každého požadavku nastavte metodu, URL a tělo. U metod GET a DELETE tělo obvykle nebývá potřeba, u POST a PUT naopak. V záložce Body zvolte raw a formát JSON, pokud API očekává JSON. Častá chyba je zapomenutá hlavička Content-Type: application/json. Bez ní server tělo ignoruje nebo vrátí chybu 415. Stejně tak si dejte pozor na to, zda posíláte data jako form-data, x-www-form-urlencoded nebo raw – záměna vede k nečitelným chybám.

První praktický krok je pojmenovat, co přesně se má spojit. Nestačí říct, že se „vše propojí". Sepište konkrétní seznam vstupů, výstupů a rozhraní mezi nimi. U každého rozhraní určete, kdo ho vlastní, kdo ho schvaluje a jak se pozná, že je hotové. Tím vznikne mapa, podle níž se dá dělat pořádek. Bez ní se lidé dohadují o pojmech a každý má jinou představu o tom, co je vlastně hotovo.

Prvním krokem je zvolit si nástroj a nainstalovat si ho lokálně. Většina vývojářů skončí u Gitu, protože je všude a funguje i bez připojení k síti. Po instalaci si nastavte jméno a e-mail, které se budou zapisovat do historie. Pak si v kořeni projektu spusťte inicializaci repozitáře. Tím vznikne skrytá složka, do které nástroj ukládá všechny změny. Tuhle složku nikdy needitujte ručně a nikdy ji nemažte, pokud si nejste jistí, co děláte.

Co patří do historie a co ne Než uděláte první uložení stavu, vytvořte soubor, který řekne nástroji, co má ignorovat. Do něj patří složky s nainstalovanými závislostmi, dočasné soubory, lokální konfigurace s hesly a cokoliv, co se generuje automaticky při buildu. Typická chyba začátečníka je, že tam tyhle věci nedá a pak řeší konflikty v souborech, které nikdy neměl verzovat. Platí jednoduché pravidlo: do historie patří jen to, co jste napsali vy a co je potřeba ke spuštění projektu na jiném počítači.

Jakmile zvládnete ukládat změny, naučte se pracovat s větvemi. Větev je oddělená linka vývoje, na které můžete zkoušet nové věci, aniž byste rozbili funkční verzi. Pro malé úpravy stačí jedna hlavní větev, pro větší práci si vytvořte novou, dokončete ji a pak ji sloučte zpět. Při slučování může dojít ke konfliktu, když stejné místo upravily dvě větve. Není to katastrofa – otevřete soubor, vyberte správnou variantu a uložte výsledek.

Poslední věc, kterou je potřeba zařídit brzy, je záloha historie mimo váš počítač. Lokální repozitář vás ochrání před vlastními chybami, ale ne před selháním disku. Přidejte si vzdálené úložiště a po každé dokončené práci tam změny odešlete. Tím získáte třetí vrstvu jistoty: máte aktuální stav, máte historii a máte i kopii mimo stroj. Až tohle budete dělat automaticky, přestanete řešit, co jste kde rozbili, a začnete řešit skutečnou práci.

Verzování není jen nástroj pro odevzdávání projektů do školy. Pro webového vývojáře je to základní pracovní návyk, který rozhoduje o tom, jestli strávíte páteční odpoledne hledáním, co jste včera rozbili, nebo jestli jdete domů včas. Pokud ještě žádný systém nepoužíváte, začněte hned u prvního souboru, ne až u velkého projektu. Zvyk se tvoří na malých věcech.

Kde se projekty s V lámou nejčastěji Typická chyba je společný plán bez společných milníků. Každá část má vlastní termíny, ale chybí body, v nichž se výsledky skutečně spojí a ověří. Druhá častá chyba je jeden vedoucí pro všechno. Ten pak nestíhá a rozhodnutí se hromadí. Lepší je rozdělit odpovědnost po oblastech a zavést krátké pravidelné schůzky jen nad rozhraními, ne nad celým projektem. Třetí chyba je odkládání integrace na konec. Čím déle se části vyvíjejí odděleně, tím dražší je jejich spojení.

Označení „projekty s V" obvykle znamená zakázky, u nichž se na začátku sejde více vlastníků, více vstupů nebo více variant řešení a výsledek má vzniknout jejich spojením. Právě to spojení bývá kámen úrazu. Dokud se pracuje po jednotlivých liniích, jde vše hladce. Jakmile se mají výstupy slít do jednoho celku, objeví se konflikty v datech, v odpovědnostech i v termínech. Vyřešit se to nedá na konci, kdy už je pozdě. Musí se to ošetřit hned na začátku.