Verzování v Gitu, které si rozbiješ hned první den

Po odeslání změny čekejte. Správci jsou dobrovolníci a mají vlastní práci. Pokud do týdne nikdo nereaguje, slušně se připomeňte v diskusi pod návrhem, ne soukromou zprávou. Když dostanete zpětnou vazbu, berte ji věcně. Recenze kódu není útok na vaši osobu. Pokud s něčím nesouhlasíte, vysvětlete proč a nabídněte alternativu. Argument „mě to takhle funguje" nestačí.

Poslední pravidlo zní: verzujte i drobnosti a průběžně. Odkládat první commit do chvíle, kdy je vše hotové, znamená přijít o celou historii rozhodování. Radši méně souborů a častěji než jeden velký krok jednou za měsíc. Verzování není administrativa navíc, je to nástroj, který vám umožní vrátit se k funkčnímu stavu, porovnat varianty a vysvětlit, proč je kód takový, jaký je.

Před sloučením větve si vždy projděte rozdíly, které přináší. Nejde o formalitu – právě tady se odhalí omylem přidaný soubor, nechtěná změna konfigurace nebo konflikt, který jste vyřešili špatně. Pokud pracujete ve více lidech, sloučení do hlavní větve dělejte přes požadavek na sloučení, ne přímým zápisem. Ušetříte si situaci, kdy jeden vývojář přepíše práci druhého, protože měl lokálně starší verzi. Stejně tak nikdy neposílejte do sdíleného repozitáře přepsanou historii bez předchozí domluvy s ostatními.

Základní dělení je mezi permisivními licencemi a copyleftovými. Permisivní licence dovolují kód použít i v uzavřeném produktu, obvykle stačí zachovat informaci o autorství a text licence. Copyleftové licence naopak vyžadují, aby odvozené dílo zůstalo pod stejnou licencí. Rozdíl se neprojeví u samostatně volaného programu, ale u kódu, který se stane součástí výsledného binárního celku. Právě tam vzniká nejvíc sporů.

Typické chyby, které potkáte: příliš velký první návrh, chybějící testy, nerespektování konvencí projektu a ignorování automatických kontrol. Tyto kontroly často spouštějí testy a analýzu stylu ještě před lidskou recenzí. Když selžou, opravte je a nahrajte novou verzi. Nikdy nemažte komentáře recenzentů ani historii větve účelovými přepisy, pokud vás k tomu projekt výslovně nevyzve.

Začít s verzováním není o tom naučit se nazpaměť desítky příkazů. Většina webových vývojářů selže na něčem jiném: začnou verzovat příliš pozdě, příliš pozdě si nastaví ignorování souborů a příliš dlouho pracují přímo v hlavní větvi. První krok proto není instalace nástroje, ale rozhodnutí, co vůbec verzovat a co ne. Do repozitáře patří zdrojový kód, konfigurace šablon a skripty. Naopak závislosti, build artefakty, lokální konfigurace s hesly a nahrávané soubory od klientů tam nepatří. Pokud tohle nerozlišíte hned na začátku, první commit bude obsahovat tisíce souborů a historie se stane nepoužitelnou.

Na co se zapomíná nejčastěji: nastavit si jméno a e-mail, aby byly commity dohledatelné, a zkontrolovat, že v repozitáři nejsou přístupové údaje. Klíče, hesla a tokeny se do historie dostanou snadno a odstranit je zpětně je otrava. Pokud se to stane, okamžitě tyto údaje zneplatněte, ne až po úklidu historie. Dále si zvykněte před každým commitem spustit, co se spustit dá – testy, kontrolu stylu nebo alespoň build. Verzování samo o sobě kvalitu nehlídá, jen uchovává to, co mu předáte.

Pro datové vstupy použijte fixture soubory nebo továrny na testovací data. Místo ručního vytváření objektů v každém testu definujte šablony s výchozími hodnotami a v konkrétních testech měňte jen to, co je podstatné. Vazby mezi daty simulujte pomocí jednoduchých struktur, které respektují referenční integritu. Například místo skutečné databáze použijte kolekci v paměti, která se na začátku testu naplní a na konci vyčistí. Pokud testujete chování při výpadku, simulujte chyby – vyhoďte výjimku, nastavte časový limit nebo vracejte neúplná data.

Po přijetí změny se nebojte ptát, co dál. Většina projektů vede seznam úkolů vhodných pro nováčky. Přispívání je dovednost jako každá jiná – první krok je nejtěžší, druhý už jde snáz. Vytrvejte u jednoho projektu alespoň několik měsíců. Naučíte se jeho architekturu, získáte důvěru správců a příště už budete řešit zajímavější problémy než překlepy.

Praktický postup: vyber dva kandidáty, každému věnuj dva týdny, napiš v každém jeden malý program, který něco dělá — třeba načte vstup a vypíše výsledek. Podle toho, který ti sedl lépe, se rozhodni. Ne podle toho, co říkají ostatní, ale podle toho, jestli tě práce s jazykem baví a jestli rozumíš tomu, co píšeš. První jazyk není doživotní závazek. Je to nástroj, který ti otevře dveře k dalším.

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.