Nr taska i jakiś akt strzelisty bo i tak wiem że ktoś nadpisze moje zmiany robiąc rebase'a
1
1
Najpierw na feature branch robię tak:
<TaskID> Prosty opis
- opcjonalny dokładny opis 1
- opcjonalny dokładny opis 1
Ale się nie nadwyrężam, bo to jest bardziej dla mnie, bo przed merge i tak robię squash commit.
Sqush commit robię ręcznie i wtedy jeszcze raz edytuję opis commitów, w większość wykorzystuję opis commitów z feature branch, ale i tak sporo z tego idzie do śmieci.
Dość często zamiast jednego squasha robię ich 2 lub 3 (interactive rebase), jeśli uważam że zmiany są słabiej ze sobą związane.
Czasem ten podział opiera się o TDD/BDD najpierw failujące testy a potem kod produkcyjny.
Kocowe commity wyglądają tak:
<TaskId> Feature title
- feature detailed description (~5 linii)
- był problem z A
- był problem z B
- ten test zmieniony bo
Średnio wychodzi mi 20 linii opisu.
Pisząc myślę co sam bym chciał przeczytać za 2 lata, jakbym zobaczył tą zmianę.
4
katakrowa napisał(a):
Czy to, że system od ponad 10 lat działa bezbłędnie nie ma żadnego znaczenia?
O to mnie zaciekawiło. Serio - nie widziałem jeszcze używanego i nietrywialnego systemu, który nie miałby błędów ... przez 10 lat :-O ?
Weź może opatentuj metodykę czy coś, bo raczej bym powiedział, że przebija to nawet najlepsze systemy militarne/kosmiczne.
5
od lat stosuje i sprawdza mi sie:
<ID>: <topic> - <short update message>
np:
...
JIRA-123: Client status - draft
JIRA-123: Client status - subscription logic
JIRA-123: Client status - refactor
JIRA-123: Client status - extra logging
JIRA-123: Client status - overflow bug fix
...
jak ktos chce sobie poczytac o szczegolach zmiany to commit jest w zasiegu reki, jak chce kontekst biznesowy to ma ID
2
Meini napisał(a):
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.
Pracuję w takich „warunkach” i to nawet ma jakiś sens. W projekcie językiem mówionym jest polski. Polak do Polaka nie gada po angielsku, bo po co. Przy czym firmowy czat to też jest „mowa pisana”, więc jest po polsku chyba że odbywa się z obcokrajowcem.
Ale językiem pisanym projektu jest angielski. Tak są opisywane wszystkie taski, dokumentacja, tak jest pisany cały kod wraz z komentarzami, tak są pisane komentarze w code review. Wszystko co w założeniu nie jest rozmową na żywo - jest po angielsku.
Trochę to przypomina dawne czasy, gdy językiem pisanym była łacina. Tylko jest angielski w miejsce łaciny.
1
ID zadania z Jiry, rodzaj zadania (bug, task), tytuł zadania z Jiry.
0
Kiedyś pisałem "dobre" a teraz piszę złe (wg większości definicji). Otóż gdy pracowałem w zespole gdzie się faktycznie coś dało dowiedzieć i każdy pisał "dobre" opisowe z numerem tasku, to działało świetnie. Nigdy wcześniej ani później się z tym nie spotkałem. Albo tylko niektózy tak robili, albo nikt. Jak masz jeden "dobry" commit a reszta to add add add fixed add new stufff... to nie ma sensu się wsysilać. Tak samo jeśli nie zaglądasz w ogóle w loga z tego czy innego powodu.
Próowłem "równać w górę" ale mi się znudziło. I piszę po prostu bardzo lakoniczny opis. Do poziomu add czy fixed nie schodzę, ale nie już nie chce mi się pisać czemu coś zmieniłem. (oprócz sytuacji wyjątkowych, gdzie wiem że to co robię jest nieoczywiste, kontrowersyjne, lub nielogiczne, ale jest jakiś powód).