Co se stane, když pošlete svůj první pull request

Začni tím, že si vybereš jeden jazyk a jednu oblast. Kombinace backend v Javě nebo v Pythonu, případně frontend v JavaScriptu, stačí. Rozšiřování do pěti technologií najednou vede k tomu, že v žádné nejsi použitelný. Vytvoř si tři projekty, které spolu nesouvisí: jeden jednoduchý nástroj na zpracování dat, jeden s databází a jeden s voláním externího rozhraní. Ke každému napiš krátké README, co to dělá, jak to spustit a co jsi musel vyřešit. To je materiál, který na pohovoru obstojí lépe než seznam kurzů.

Po odeslání pull requestu čekejte na reakci. Může trvat dny i týdny, protože správci dělají na projektu ve svém volném čase. Když dostanete připomínky, berte je věcně a upravte kód podle nich. Obrana a vysvětlování, proč je vaše řešení správné, vede jen k zbytečným konfliktům. Pokud projekt o změnu nemá zájem, není to osobní selhání — zkuste jiný projekt nebo jinou Issue. Vytrvalost a schopnost přijmout zpětnou vazbu nakonec rozhodují víc než technické znalosti.

První přijatý pull request je zlom. Otevře vám dveře k dalším úkolům, získáte přístup k diskusím a postupně vás začnou brát jako součást týmu. Přispívání do open source není soutěž o největší počet commitů, ale dlouhodobá spolupráce. Stačí začít malou opravou, dodržet pravidla projektu a vydržet u něj dost dlouho na to, aby si vás ostatní všimli.

Oddělené verzování není jen otázka pořádku. Umožňuje nasazovat stejný artefakt do různých prostředí, snižuje riziko úniku citlivých údajů a zkracuje dobu, za kterou se najde příčina chyby. Pokud už teď máte konfiguraci v kódu, začněte tím, že oddělíte tajemství a přidáte validační vrstvu. Zbytek lze přesouvat postupně, prostředí po prostředí, aniž by se musel zastavit vývoj.

Malá změna, jasný popis, trpělivost První příspěvek držte co nejmenší. Oprava překlepu v komentáři nebo doplnění chybějícího testu má větší šanci projít než rozsáhlý refaktoring. Do popisu změny napište, co a proč měníte, a připojte odkaz na související hlášení o chybě, pokud existuje. Vyhněte se mixování několika nesouvisejících úprav v jednom návrhu – to je nejčastější důvod, proč správci změnu vrátí k přepracování. Formátování, mezery a styl odsazení držte shodné s okolním kódem.

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.

Vlastní změnu dělejte v nové větvi vytvořené z aktuálního stavu hlavní větve. Do commitu pište krátké a výstižné zprávy, které popisují, co se změnilo a proč. Vyhněte se commitům typu „oprava" nebo „úpravy" — správce projektu nemá čas luštit, co jste tím mysleli. Pokud měníte chování programu, přidejte k tomu test a ujistěte se, že prochází i ty stávající. Jeden pull request by měl řešit jednu věc. Když do něj přimícháte tři nesouvisející úpravy, výrazně se sníží šance, že ho někdo přijme.

Než napíšete první řádek kódu Přečtěte si soubor s pokyny pro přispěvatele. Bývá pojmenovaný jako CONTRIBUTING a obsahuje pravidla pro formátování, větev, do které se posílají změny, a způsob testování. Ignorování tohoto souboru je nejčastější důvod, proč je pull request zamítnut během několika minut. Stejně důležité je projít si existující Issues a pull requesty, abyste neřešili něco, co už někdo jiný rozpracoval. Někdy stačí napsat do komentáře pod Issue krátkou zprávu, že na tom pracujete, a domluvit se na postupu.

Před sloučením vždy spusťte testy na aktuálním stavu hlavní linie, ne na tom, ze kterého jste vycházeli. Zkontrolujte, zda větev neobsahuje zapomenuté zakomentované bloky, dočasné výpisy do logu nebo soubory, které do repozitáře nepatří. Sloučení provádějte co nejdříve po dokončení funkce; odložený merge znamená, že se mezitím změní okolní kód a vyřešený konflikt se může vrátit v jiné podobě.

Při oddělování pomáhá i to, že se konfigurace testuje zvlášť. Napište test, který ověří, že aplikace nastartuje s minimální sadou proměnných, a test, který ověří chování při chybějící hodnotě. Tím odhalíte závislosti dřív, než se dostanou do produkce. Zároveň mějte v kódu jasnou chybovou zprávu, která řekne, která proměnná chybí a jaký má formát. Bez toho se ladění konfigurace zvrhne v hádání.

Začít přispívat do open source vypadá složitě jen do chvíle, než pochopíte, že nejde o vstup do nějakého uzavřeného klubu. Projekty naopak nové přispěvatele aktivně hledají, protože bez nich stagnují. Rozdíl mezi těmi, kdo přispívají, a těmi, kdo jen přemýšlejí o tom, že by mohli, je většinou v tom, že první jmenovaní si našli malý, konkrétní problém a vyřešili ho. Zbytek je řemeslo, které se dá naučit.