Jak pojmenovávat commity v Gitu, aby byl pěkný changelog?
Ahoj,
mohl by mi, prosím, někdo ze zkušenějších dát pát tipů na pojmenovávání commitů?
Ne zrovna moc přehledný changelog - CHANGELOG.md
Pěkný přehlednější changelog - CHANGELOG.md
Jde mi o to, jakým způsobem mám commity pojmenovávat, aby se mohl vygenerovat changelog s těmi skupinami (added, changed, fixed, removed...) - 1.0.0. Zrejmě špatně hledám, ale nenašel jsem to, takže se ptám zde. :)
Díky.
Píšou ho ručně.
To je možné, ale před nějakou dobou mi někdo říkal, že se to určitým zápisem zprávy commitu dá zautomatizovat. :)
Ano, trochu se to zautomatizovat da, pokud si zavedes nejaky snadno pasovatelny styl pojmenovavani commitu, pak ho budes dusledne dodrzovat a napises si skript/program, ktery ti to z tech nazvu sestavi. Ale aby to opravdu bylo hezke a citelne, tak to stejne budes dodelavat rucne.
Ostatne o tom, jak to psat je ten treti odkaz (1.0.0), kde popisuji, jak to psat a vyslovne pisou, ze automaticke generovani z commitu neni zrovna dobry napad.
A ta tvoje ukazka hezkeho changelogu je taky upravovana rucne - vsimni si, ze u nekterych PullRequestu (PR) se nazev lisi od toho, jak jsou v changelogu uvedeny - nekdo to prepsal rucne, aby to lip vypadalo.
---
Jinak je dobry napad mit nekolik hlavnich a vyvojovych vetvi a vsechny upravy delat v samostatnych feature vetvich, ktere, pote co projdou testy, mergnes do nich hlavni vetev a opet projdou testy, tak zmacknes do jednoho commitu pomoci squash (dohledej si) a feature vetev tim momentem prestanes pouziva a po nejake dobe ji proste smazes. (branche jsou zdarma, je normalni jich mit otevrenych vic, nez je featur, na kterych zrovna delas a zakladat dalsi pro kazdou ptakovinu, kde to dava aspon trochu smysl. Navic, pokud pokracujes tim squash commitem a smazanim vetve, tak po garbage collektoru se ti zmensi celkovy repozitar o (nyni jiz) zbytecne commity)
Takze hlavni vyvojova vetev sestava pouze z commitu, ktere ucelene resi nejaky problem, jsou bezchybne (v ramci moznosti - prosly testy automatickymi i rucnimi, pripadne zkusebnim provozem), jsou male (kazdy obsahuje jen jeden problem a resi ho jednim ucelenym krokem) a jsou rozumne nazvane ( napr. "Oprava chyb pri parsovani exotickych textu" misto puvodniho nazvu feature vetve "bugfix#321" s commity jako "4 rano, jdu spat", "fix unicode parsovani", "oprava fixu", "oprava jeste pro japonstinu", "temp" ...).
Nasledne hlavni release vetev ma jeste vic "zdrcnute" commity, kdy z vyvojove prevezmes cely odladeny blok a nazves ho souhrnym nazvem ( napr. "Podpora Unikodu" a nasledny "Lokalizace pro 5 svetovych jazyku a cestinu" - vybrane cherrypickem (a zdrcnute squashem) z vyvojove vetve).
A pak Oddeleni pro styk s verejnosti nakresli a vytiskne letaky "Nova verze !! Nyni vse bude lepsi a barevnejsi a tentokrat bez chyb !! Reknete JUJKY !!", ktere rozvesi vsude mozne i nemozne a zaplati si umelce, aby ji na kameru rikaly JUJKY!! (veskera podobnost s kampanemi znamych spolecnosti je ciste nahodna). A to uz je zcela ciste rucni a tvurci prace, ktera s commitama (a vlastnim kodem) nesouvisi uz vubec, ale je prezentovana verejnosti a dobre se cte.
Díky moc za tipy. :)
Poměrně pěkně je to popsané vlastně i tady (jen anglicky) a jde o celkový náhled vývoje, nikoli pojmenovávání (ale to je důsledek dobré správy). A samozřejmě to není dogma, uprav si to na své podmínky (a hlavně si promysli proč to tak je a co vlastně chce docílit autor a co vlastně chceš docílit ty)
https://nvie.com/posts/a-successful-git-branching-model/
dále tě můžou zajimat hooky https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks ( vůbec celá tato kniha, částečneě je i přeložená do češtiny, já raději čtu v originále, pokud jím je angličtina ) kam můžeš zaháknout skript na vytváření hezkého changelogu
ten skript by kupříkladu mohl použít i něco jako
(dohledej si co to znamená - git help log )
a nějak si to přechřoustat a pokud se "čistě náhodou" rozhodneš ty commity pojmenovávat ve stylu
added: Podpora Unikódu
changed: Nový tvar konfiguračních souborů
fixed: Chyby při dělení nulou a při sčítání jablek s hruškama
removed: Odstraněna podpora DOS 2.1 a nižších verzí
tak mu to třídění a parsování půjde mnohem lépe od ruky a ta klíčová slova může z výsledného *.md cudně vynechat a místo toho před každou sekci dát předdefinovanou hlavičku (klidně i pár odstavců) a tím ti ušetřit mechanickou práci
Knihu jsem před časem tak nějak proletěl a ty základy mám.
Zrovna dnes jsem se dopátral, že někdo commity pojmenovává jako:
Těmi uvozovkami si tam nejsem jist. Nevypadá to špatně, taky by se to nějak dalo naparsovat, ale ten tvůj uvedený způsob se mi líbí o něco víc. Opět díky. :)
Ja jsem si zvykl na format
changelog se pak da vygenerovat pres
Pak je ale hezci, kdyz se do masteru rebasuje nebo merguje pouze fast forwardem (a idealne vse squashnute do jednoho commitu).