Jak piszecie commit message?

U mnie zwykle wygląda to mniej więcej tak:

<ID zadania> <One-liner>

[<Lista zmian> | <Opis zmian prozą>] 

[<Wyjaśnienia>]

Zmiany zdecydowanie częściej jako lista, niż proza, im zmiany są większe / bardziej kontrowersyjne / bardziej pokićkane tym więcej elementów pojawia się w commit message - nie widzę sensu produkować się z wyjaśnieniami, jeśli sam one-liner praktycznie wyczerpał temat ;)

TODO / FIXME czasami sobie dodaję, dopóki pracuję na swoim branchu, ale finalnie staram się ich pozbyć nim skończę, więc przy finalnym squashu radosnego ulepku wylatują.

Numer zadania Opis Np "XYZ-222 Refactored service ZYX"
Bitbucket ładnie sobie to z jirą matchuje i robi z numeru zadania hiperlink :)

<id zadania> <one liner>

nie piszę kodu, który wymaga wyjaśnień w wiadomości przy commicie ;)

W moim odczuciu to tracisz czas. Opis prozą umieść w JIRA (ewentualnie umieść wszystko w szablonie, jeśli taki używacie), a jakieś techniczne wyjaśnienia fikołków w kodzie dodaj do opisu pull requesta. Zwykle się tego nie stosuje, jeśli pisze się czytelny kod. Jak potrzebujesz zobrazować coś na grafice, to od tego są załączniki w JIRA.

Taki szablon, jaki zaproponowałeś, nie zawsze da się wykorzystać, pracując na swojej gałęzi. Często zdarza mi się commitować np. dwie rozgrzebane funkcje albo UT, które nie mają funkcji. Jakoś nie widzę potrzeby dodawania szczegółowego opisu, skoro za 2, 3 commity będzie to dopiero gotowe.

Opisuje krótko co popsułem. Jeśli jest ździra, to dorzucam ID.

W kodzie firmowym to pisze zwykle numer taska ze zdziry i jakiś zwodniczy komentarz. Dwa - trzy słowa, które za pół roku spowodują, że ktoś czytający ten commit message mocno podrapie się po głowie, próbując zrozumieć jak to się ma do zmian.
U Siebie - wrzucam byleco.

Jest ID = można się połapać po co to było, to niezbędne minimum - OK, reszta do ustalenia ze 'jak było do tej pory niechaj dalej będzie, po commity commitów, amen'

Imo:

• issue - opis zadania,
• commit message - co zostało zmienione (dobrze jest podać nr issue),
• komentarz w kodzie - dlaczego coś zostało zrobione w dany sposób (ale tylko kiedy taka informacja jest niezbędna),
• kod - jak coś zostało zrobione.

superdurszlak napisał(a):

U mnie zwykle wygląda to mniej więcej tak:

<ID zadania> <One-liner>

[<Lista zmian> | <Opis zmian prozą>] 

[uważam, że] Jeśli zmiany są na tyle złożone, że jest ich cała lista, to każdy element tej listy powinien być osobnym commitem.