Jak piszecie commit message?

0

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ą.

2

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

1
<id zadania> <one liner>

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

0

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.

1

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

0

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.

0

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'

0

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.
3

title

1
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.

3

Widzieliście commit message Torvaldsa? Przykład https://github.com/torvalds/linux/commit/472e5b056f000a778abb41f1e443de58eb259783

0

Czasem pisze cos o zabarwieniu humorystycznym, zwykle jednak opis zmiany plus id systemu ticketowego

0

ID taska (jeśli taki jest) + krótki opis.

0
IHaveHandedInMyResignation napisał(a):

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

Powinno się używać trybu rozkazującego, pisząc co ten commit zrobi gdy go użyjesz, a nie co Ty zrobiłeś żeby uzyskać ten commit
https://chris.beams.io/posts/git-commit/#imperative

A więc nie Refactored service ZYX tylko Refactor service ZYX
No chyba że dla konsekwencji zmieniasz message z "Merge pull request #190" na "Merged pull request #190"

U mnie zazwyczaj zawsze w pracy było

<JIRA-ID> <Tytuł jiry>
lista zmian

Ale widzę że w większych projektach, zwłaszcza open source nie używa się numer jiry, a tego zazwyczaj chcą managerowie żeby łatwiej uzyskać listę zmian, po czym nigdy do niej nie zaglądają. W obecnym projekcie mam nawet skrypt który porównuje commit releasa z ostatnim, wyciąga numery JIRY i na podstawie jiry robi changelog do wersji, ale moim zdaniem to trochę nadużycie tych wiadomości i raczej coś takiego powinno być generowane z jiry, a numer jiry przy commicie i tak mało kiedy się przydaje - rozumiem że czasem można tam znaleźć przy dobrych wiatrach rozmowę z jakimiś analitykami albo dodatkową dokumentację, ale przy starym kodzie zazwyczaj i tak ciężko dojść do tej jiry bo commit wskazuje albo na jakiś refaktoring, albo na całkiem niezwiązaną zmianę gdzie ten kod tylko został ruszony. Commit messagem można też kontrolować stan jiry, a czasem nawet wydawać polecenia żeby task zamknąć albo zalogować czas, ale dla mnie to już jest totalnie poroniony pomysł i nikt zresztą nigdy nie pamięta jak to zrobić i tak każdy potem idzie do jiry i sprawdza na wszelki wypadek czy się status zmienił.
Osobiście wolałbym gdyby commit zawierał czystą listę zmian i tak robię przy własnych projektach. Ale we własnych projektach też często commituję z messagem typu "aazgah"

3

Fix
Fix
Fix
Final fix
Final fix 1
Fix finally
Hopefully fix
Fix

0

initial commit
Fix.
Revert fix.
feature
revert feature
resolve conflict
fix resolve conflict

cd .. && rm -rf repo
git clone repo

0
obscurity napisał(a):
IHaveHandedInMyResignation napisał(a):

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

Powinno się używać trybu rozkazującego, pisząc co ten commit zrobi gdy go użyjesz, a nie co Ty zrobiłeś żeby uzyskać ten commit
https://chris.beams.io/posts/git-commit/#imperative
A więc nie Refactored service ZYX tylko Refactor service ZYX
No chyba że dla konsekwencji zmieniasz message z "Merge pull request #190" na "Merged pull request #190"

To opinia, nie reguła.
Wg mnie wręcz przeciwnie.
Słowo log wg G to: "an official record of events during the voyage of a ship or aircraft."

To że projekt Git ma taką wewnętrzną regułę przy submitowaniu do nich zmian nie znaczy że projekty które używają gita też mają się do tego stosować.

Zobacz również: https://stackoverflow.com/a/8059167

Ale widzę że w większych projektach, zwłaszcza open source nie używa się numer jiry, a tego zazwyczaj chcą managerowie żeby łatwiej uzyskać listę zmian, po czym nigdy do niej nie zaglądają.

W projektach GitHub używasz w commit message numeru issue w formacie #123: corrected user label.

0

We własnych projektach - https://www.conventionalcommits.org/en/v1.0.0-beta.2/

W firmie:

(FIX|FT) <JIRA-ID>: <tytuł>

<opis>
2

W swojej gałęzi piszę jednolinijkowy opis działania (cośtam fixed/created/removed/renamed/refactored). Nie ma po co podawać id taska, bo ten jest w nazwie gałęzi.
Do mastera wbijam już z ID taska i jednolinijkowym opisem zaimplementowanego ficzera.

2
obscurity napisał(a):

Powinno się używać trybu rozkazującego, pisząc co ten commit zrobi gdy go użyjesz, a nie co Ty zrobiłeś żeby uzyskać ten commit
https://chris.beams.io/posts/git-commit/#imperative

Jedyne co powinno być robione to tworzenie precyzyjnych i łatwych do zrozumienia opisów, najlepiej zawierających identyfikator zadania.
To że ktoś sobie używa typu rozkazującego to jest wyłącznie jego konwencja a nie powinność każdego programisty na świecie. Jeśli w zespole jakaś została już przyjęta to należy jej używać żeby zachować spójność (chyba, że jest niedobra to trzeba zaproponować zmianę).

0

Zawsze wpisuję tekst "Poprawki". W ten sposób nie muszę myśleć co wpisać, a gdyby ktoś chciał zobaczyć co się zmieniło to może sobie przecież zobaczyć.

2

Zawsze numer ticketa, jeśli to fix to dopisuję. Jeśli problem jest dziwny i potem szukałabym po tym słowie jakiejś zmiany to staram się to opisać.

0
Review changes

:D

0

git ci -am "S". S bo najwygodniej. a jak po PR to "review koments"

0

Zawsze tak żeby to coś ze sobą niosło ...

screenshot-20201005151148.png

screenshot-20201005151454.png

0

@Pinek ale że po polsku? ;)

Wiedziałem, że wzbudzi kontrowersje bo nie po myśli statystycznej większości.
Mieszkam w Polsce, pracuję w Polsce, wszyscy moi pracownicy to Polacy system piszę dla Polaków i w całości dostosowany jest do polskiego prawa, klienci zadają pytania po polsku i po polsku im odpowiadamy.. Jaki byłby sens pisania opisów commit'ów w innym języku?
Więcej powiem w głównej aplikacji systemu w bazie danych wciąż jeszcze mamy Polsku ponazywane tabele w stylu SCREAMING_SNAKE_CASE ... Wiem, że u niektórych to wywołuje straszny "bool-poopy" :-)

Myślisz, że powinniśmy wszystko przepisać na angielski do jakiegoś nowoczesnego JavaScript frameworka albo nodeJS bo jesteśmy "niemodni'? Czy to, że system od ponad 10 lat działa bezbłędnie nie ma żadnego znaczenia?

1

Moim zdaniem pisanie commitów po angielsku gdy w zespole nie ma i nie będzie obcokrajowców nie mówiących po.polsku to czysty debilizm. To tak, jakby dokumentację i firmowe maile pisać w takim przypadku po angielsku.

1

Jeżeli planujesz zabetonować swój projekt w pl, to jak najbardziej nie ma sensu. Zawsze jakiś argument przeciwko przeniesieniu do Indii.
Niestety większość biznesów woli zabezpieczać się na wypadek, gdyby projekt wypalił i wszedł na zagraniczne rynki.
Trzymanie projektu w starożytnej technologii też ma sens, jeżeli nie planujesz się rozwijać. W innym wypadku skończysz jak reddit, który musiał przepisywać na inny język, bo nie było devów lispa.

1

W temacie koduję w Polsce i po polsku sparafrazuję znane powiedzenie Tomasza Lisa.

Programiści nie są wcale tacy głupi, tylko mają skłonności żeby utknąć w lokalnych firmach.

Ludzie nie są tacy głupi jak nam się wydaje, są dużo głupsi.
Tomasz Lis

1 użytkowników online, w tym zalogowanych: 0, gości: 1