No, nevim jak David, ale ja vetsinou resim vyvoj tak, ze
- udelam adresar pro novy projekt,
- do nej dam soubor README, ktery obsahuje asi tak jednu vetu o cem to bude
- zalozim gitovy repozitar a hrde tam ten README commitnu
pak napisu bud naznak struktury s tim, ze jednotlive funkce povetsinou jen vypisou svuj nazev (kdyz jdu zrovna shora dolu), nebo naopak zacnu psat nejakou zajimavejsi cast kodu zevnitr a udelam nejaky minimalisticky programek (tedy takovy, ze to s nim uz jde aspon zkusit prelozit) test_fce_xyz, ktery tomu podstrci vsechny parametry a pripadne vstupy a vypise promenne, ktere se tvari zajimave.
Jakmile mam aspon nejaky kousek, ktery se tvari ze by mohl davat smysl a nehaze pri prehladu prilis mnoho chyb, tak ho zase commitnu a pisu dal.
Samozrejme komituju, kdyz od toho na delsi dobu odchazim (treba vecer, kdyz jdu spat, nebo kdyz jdu na obed ven), celkem bez ohledu na to, zda to vubec jde prelozit. A rozhodne commituju nez se pustim do nejake opravy slozitejsi nez preklepy, chybejici stredniky a nesparovane zavorky a pote, co se mi tu opravu podari nejak odladit.
Asi tak kolem 10 commitu uz to povetsinou je ve stavu, kdy to "fakt skoro jako neco dela" - tedy napriklad u tebe to na serial vypise kod HTML stranky, ktery neni na prvni pohled zcela blbe.
kolem tak 20-30 commitu uz to "neco dela doopravdy", i kdyz treba ne zdaleka vsechno a spravne, ma to v sobe nekde cislo verze ("0.0.1-rc28 from 2017.12.19 22:42") a je pomalu cast to zacit brat vazne jako projekt, ktery ma sanci na to nekdy fungovat.
Takze oznacim vrcholek jako feature branch, nebo tak neco, hlavni branch vratim na to uvodni README a squasnu do nej cely ten vyvoj jako jeden krok s tim, ze zvednu verzi na "0.0.2" a rovnou udelam dalsi feature branch, ve kterem zase vrsim jednotlive mensi kroky, ze kdyby se neco rozbilo, nebo jsem neco omylem smazal, tak se k tomu snadno muzu vratit.
Po nekolika dalsich podobnych iteracich se teprve dostanu k necemu jako 0.1.0, co uz "celkem funguje" (akorat tomu zadrhava refresovani stranek a neumi to zaporne teploty, nebo tak neco, ale uz se to celkem da pouzivat).
Kdyz se nejaka verze doopravdy osvedci, tak neni problem ten verzovaci system procistit, vyhazet vsechny pomocne vetve (a treba to i prohnat garbage colectorem, nebo proste prekopirovat do noveho repozitare jako juvodni a jediny commit a odriznout tak celou tu rozvrkocenou historii).
Klavesnice s STM, kterou jsem na minulem robodoupeti predvadel byla commit cislo 74 v hlavni rade a jeste porad neumela emulovat USB klavesnici, vybrat ovladac jinak nez cyklicky dokola a jednotlive funkce proste padly, pokud se stalo neco necekaneho na I2C sbernici. Ale uz jezdila robotkem (Zumo), a psala dvema zpusoby na tri ruzne periferie (serial, I2C display a jine arduino).
Cili rekneme, ze uz se blizim te tvoji urovni, kde ti to v prohlizeci celkem spolehlive (i kdyz s blikanim) refresuje stranky a v nich jsou nove hodnoty, ktere nejak odpovidaji jakymsi vstupum.
Proste a jednoduse verzovaci systemy jsou tu hlavne pro obdobi prekotneho vyvoje a mohutnych oprav chyb jak v provedeni, tak v koncepci, kdyz uz to cele funguje spravne a dela vsechno co ma, tak uz verzovaci system neprinasi tolik uzitku jako na samem zacatku (i kdyz pro opravy chyb a dalsi vylepseni je potreba porad).
Kdyz vyvyjime neco se synoveckem, tak klidne jsou nove commity treba co deset minut, aby se nam to moc nerozesynchronizovalo - a to sedime u jednoho stolu.
Takze IMHO fakt nejlip udelas, kdyz to do toho verzovaciho systemu vrznes "jak to lezi a bezi" i kdyz je to ho jen kousek a jeste treba ti nedela toco chces, protoze pak si kdokoli jiny muze ten existujici kus stahnout, kouknout na to jak to "zrovna ted" vypada a nemusi tu z tebe pacit, co a proc a jak. A navic si na tom muze udelat i vlastni pokusy a pouzit na to vlastni nastroje (at uz osciloskop, logickou sondu, stahovat ty stranky wgetem a ukladat kazdy refresh do jinak ocislovaneho souboru, nebo si treba projit jak je vlastne implementovany ten print/println v tom tvojem knihovnim objektu a tedy jakym zpusobem to nejlip uchopit (jestli a proc je vhodnejsi tu stranku poslat jako jeden dlouhy retezec, nebo jako par velkych kusu a par promennych, nebo kvuli bufferu to naopak posilat radeji po jednotlivych radcich, ale na konstatni retezce pouzivat radeji write, nez print, protoze (treba) ty retezce nezkousi zbytecne nejak konvetovat a porcovat na mensi casti).
Ze to cele neni hotove a ma to problemy je jasne, jinak by ses tu prece neptal na rady, tim nikoho neurazis, kdyz to priznas, ze to je treba jen fragment taky nevadi, naopak tam treba nekdo objevi nejake vyrazne neobratnosti a zbytek uz budes psat jinym zpusobem, snaz a rychleji. V open source komunite je jedna velice uzitecna zasada "release early, release often", diky ktere se na vyvoji muze podilet rada lidi s ruzne velkym nasazenim a cele to jde rychle kupredu (a proto se take rozeznavaji vyvojove vetve, release-kandidati, releasy, revize a opravy chyb), na rozdil od katedraly, ktera by nejradeji prisla s finalnim produktem jednou za 5 let a mezi tim nic, vsechno drzet pod poklickou az do slavnostniho predstaveni noveho produktu na vhodnem veletrhu.
Ten "cely kod", o kterem David mluvi neni "cela finalni verze s kompletnim ovladanim a dokumentaci", ale naopak "vsechno co zatim mas, at uz je toho jakkoli malo a je to jakkoli kuse" (cili v mem pripade bych zacal tim, ze bych hodil odkaz na repozitar, kde je README a petiradkovy fragment kodu, ktery vypise
<HTML><BODY>Maybe it just works</BODY></HTML>
a poznamka, ze se mi z nejakeho duvodu nezobrazuje jmeno stranky v liste ve firefoxu a ze jeste musim dopsat zobrazeni promennych