Když odhadujete čas na vývojový úkol, snadno se zaměříte na viditelné činnosti – psaní kódu, návrh obrazovky, nastavení databáze. Skryté činnosti, jako jsou schůzky, čekání na odpověď, ladění, testování nebo psaní dokumentace, ale tvoří často 30 až 50 % celkového času. Pokud je nevezmete v úvahu, bude váš odhad vždy příliš optimistický.<br>
<br>
<br>
<br>
Na závěr jeden praktický tip: nikdy nepoužívejte git push --force, dokud si nejste jistí, co děláte. Tento příkaz přepíše historii vzdáleného repozitáře, což může poškodit práci celého týmu. A pokud máte pocit, že jste něco pokazili, pamatujte, že Git je navržen tak, aby se dalo vrátit zpět – díky git revert nebo git reset. Ale to už je pokročilejší látka. Na začátek vám bohatě stačí init, add, commit a status. S těmito nástroji zvládnete základní verzování bez stresu a bez ztráty dat.<br>
<br>
<br>
<br>
První kroky: commit, add a časté chyby Po git init je čas na první uložení. Nejdříve musíte soubory „přidat", což uděláte příkazem git add . (tečka znamená všechny soubory). Tím se soubory přesunou do takzvaného „staging area". Poté je uložíte pomocí git commit -m "popis změny". Zde se vyvarujte dvou klasických chyb: zapomenout na -m, což spustí nechtěný textový editor, a psát nesmyslné popisy typu „oprava". Popisujte, co jste změnili a proč, ať se do toho za měsíc zorientujete.<br>
<br>
<br>
<br>
Nejčastější začátečnická chyba je commitovat až po 200 změnách najednou. Git je pak k ničemu, protože když se něco rozbije, nevíte, která z těch 200 změn to způsobila. Commit by měl být malý a logicky uzavřený: jedna funkce, jeden opravený překlep, jeden styl. Pokud máte pocit, že je toho moc, rozdělte si práci na menší kroky. A nikdy necommitnete do hlavní větve (obvykle master nebo main) bez předchozí kontroly, co se v ní děje. K tomu slouží větve.<br>
<br>
<br>
<br>
Důležité je také formálně správné uvedení licence v repozitáři. Nestačí jen přidat soubor s textem licence do složky. Měli byste do každého zdrojového souboru uvést hlavičku s odkazem na licenci a autorem. To usnadní budoucí správu a právní průhlednost. Vyhněte se vytváření vlastních licencí – většinou nejsou právně ošetřené a odrazují potenciální přispěvatele. Místo toho zvolte standardní, ověřenou licenci, která má jasně definovaná pravidla.<br>
<br>
<br>
<br>
Než napíšete první řádek kódu, měli byste vědět, že Git není jen nástroj pro pokročilé. Je to váš bezpečnostní pás, kterým se vyhnete katastrofě s názvem „přepsal jsem celý projekt". Na začátku stačí pět příkazů, a když je budete používat pravidelně, ušetříte si hodiny hledání chyb. Git si představte jako časovou osu, na kterou můžete kdykoli přidat bod uložení. A teď prakticky: otevřete terminál v kořenové složce projektu a napište git init. Tím se vytvoří skrytá složka .git, která začne sledovat vše, co v projektu uděláte.<br>
<br>
<br>
<br>
Na závěr si osvojte práci s historií a sdílením. Historie požadavků vám umožní vrátit se k dřívějšímu volání, aniž byste ho museli znovu sestavovat. Pro týmovou spolupráci využijte možnost exportovat kolekci do sdíleného souboru nebo ji propojit s verzovacím systémem. Vyhnete se tak nesrovnalostem mezi členy týmu. Pamatujte také na to, že každý požadavek by měl mít popisný název a komentář, což oceníte při zpětné analýze.<br>
<br>
<br>
<br>
<span style="font-weight: 700;">Pozor na jeden častý omyl:</span> při testování autentizace neukládejte tokeny přímo do testů či do kolekce. Místo toho využijte skript v sekci „Pre-request Script", který token získá z přihlašovacího požadavku a uloží ho do proměnné prostředí. Například po úspěšném přihlášení si odpověď uložíte do proměnné accessToken a v dalších požadavcích ji použijete v hlavičce Authorization. Tím se vyhnete duplicitnímu kódu a zvýšíte bezpečnost.<br>
<br>
<br>
<br>
Vytvoření nové větve je snadné: git branch nazev-vetve vytvoří větev, a git checkout nazev-vetve na ni přepne. Zkráceně to jde i jako git checkout -b nazev-vetve. Větve jsou vaše izolované pracoviště – tam můžete experimentovat bez obav, že rozbijete hlavní kód. Až budete spokojeni, větev sloučíte do hlavní přes git merge nazev-vetve. Pozor na jednu past: pokud ve větvi provedete změny a hlavní větev se mezitím posune, může merge vytvořit „konflikt". To není nic hrozného – Git vám ukáže, kde si soubory protiřečí, vy ve správci souborů opravíte, která verze má zůstat, a pak provedete nový commit.<br>
<br>
<br>
<br>
Další věc, na kterou začátečníci často narazí, je git status. Tento příkaz ukazuje, co se ve vašem projektu děje: které soubory jsou upravené, které přidané a které ještě nejsou sledované. Berte ho jako svou GPS – spouštějte ho po každém větším kroku. Nebojte se ani git log, který vypíše historii commitů s daty a autory. Tyto dva příkazy byste měli používat častěji než samotný commit, protože vám dají zpětnou vazbu o stavu vaší práce.
