Přidat otázku mezi oblíbenéZasílat nové odpovědi e-mailem 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ředmět Autor Datum
Píšou ho ručně.
Wikan 10.02.2019 19:13
Wikan
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á zauto…
trips 10.02.2019 19:25
trips
Ano, trochu se to zautomatizovat da, pokud si zavedes nejaky snadno pasovatelny styl pojmenovavani c…
gilhad 10.02.2019 22:02
gilhad
Díky moc za tipy. :)
trips 10.02.2019 22:15
trips
Poměrně pěkně je to popsané vlastně i tady (jen anglicky) a jde o celkový náhled vývoje, nikoli pojm…
gilhad 11.02.2019 02:08
gilhad
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 c…
trips 12.02.2019 17:24
trips
Ja jsem si zvykl na format [TASK_NUMBER] popis changelog se pak da vygenerovat pres git log --one… poslední
MaSíčko 12.02.2019 17:43
MaSíčko

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.

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

git log --graph --oneline --decorate=full --color --branches

(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:


Added("Podpora Unikódu")
Changed("Nový tvar konfiguračních souborů")
...

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

[TASK_NUMBER] popis

changelog se pak da vygenerovat pres

git log --oneline --decorate

Pak je ale hezci, kdyz se do masteru rebasuje nebo merguje pouze fast forwardem (a idealne vse squashnute do jednoho commitu).

Zpět do poradny Odpovědět na původní otázku Nahoru