Příchod nového vývojáře do týmu je vždycky malá zkouška trpělivosti pro obě strany. Na jedné straně stojí člověk, který chce co nejdřív něco předvést, na straně druhé tým, který má své zaběhnuté postupy a nechce je kvůli každému nováčkovi rozbourat. První commit do společného repozitáře přitom není jen technický úkon. Je to okamžik, kdy se z návštěvníka stává člen. A pokud se to podcení, může se z prvního commitu snadno stát zdroj frustrace na obou stranách.

Než nový vývojář vůbec otevře terminál, měl by dostat jasný obrázek o tom, jak tým pracuje s větvemi, jak vypadají code reviews a co se od něj očekává. Nestačí poslat odkaz na dokumentaci a doufat, že si to nastuduje sám. Osvědčilo se projít s ním podle praktického návodu na Git workflow krok za krokem, klidně na cvičném repozitáři. Nováček si tak vyzkouší větev, pull request i rebase bez rizika, že něco rozbije v ostrém kódu. Zároveň získá jistotu, že chápe, proč se věci dělají právě takhle, a nebude se bát zeptat, když něco nesedí.

Samotný první commit by měl být malý a bezpečný. Ideálně oprava překlepu v dokumentaci, doplnění testu nebo úklid drobného dluhu, který tým už delší dobu odkládá. Nejde o to, aby nový člověk hned ukázal, co umí. Jde o to, aby si prošel celým cyklem od klonu repozitáře přes větev až po sloučení a code review. Zkušený kolega by měl být u toho, ale neměl by mu psát příkazy do terminálu. Lepší je sedět vedle, nechat ho tápat a zasáhnout až ve chvíli, kdy se zasekne na něčem, co se týká konvencí týmu, ne samotného Gitu.

Po sloučení prvního commitu je dobré si s nováčkem sednout a probrat, co šlo hladce a co bylo matoucí. Možná zjistíte, že váš workflow má slepé místo, které nikdo předtím nepojmenoval. Možná se ukáže, že dokumentace je zastaralá. Právě tyhle drobné opravy po příchodu nového člověka bývají nejcennější. Tým získá svěží pohled a nový vývojář získá pocit, že jeho hlas něco znamená. A to je přesně ten typ začátku, který se dlouhodobě vyplácí.