Dobre commity w git.

Dzisiaj słów kilka o dobrych praktykach robienia commitów. Zanim pomyślisz przysłowiowe „paaanie, a komu to potrzebne?” odpowiadam Tobie! Tak Tobie. Ci z Was którzy już przeszukiwali historię gita w poszukiwaniu konkretnej zmiany wiedzą jak ważne są dobre commity. Ci którzy jeszcze tego nie robili zrozumieją gdy spotka ich to po raz pierwszy.

Będę pamiętał co robiłem….

Taaa…. a świstak siedzi i zawija w te sreberka… 😀 Za pół roku nie będziesz miał pojęcia co oznaczają „zmiany”, „małe zmiany” i „poprawki”. Ba! jeżeli pracujesz w kilku projektach to nawet za dwa miesiące możesz mieć problemy z przypomnieniem sobie co i po co robiłeś. Nie ma w tym nic złego, nie warto zaprzątać sobie głowy co i kiedy robiliśmy.

Jestem sam w projekcie…

Często myślimy że opisy commitów są dla kolegów z zespołu aby wiedzieli co robiliśmy np. na potrzeby code review. Nic bardziej mylnego! Odbiorcą opisów może być zarówno kolega/koleżanka z zespołu, koleżanka/kolega którzy zatrudnią się po Twoim odejściu, lub (pamiętajcie że „karma wraca”) Wy sami. Jak już wcześniej pisałem nasza pamięć nie jest niezawodna.

Ok, przekonałeś mnie. Powiedz teraz jak żyć?!

Jeżeli Cię przekonałem to bardzo się cieszę, jeżeli nie przestań czytać – szkoda czasu! 🙂 Odpowiadając na pytanie jak żyć należy przytoczyć kilka bardzo prostych zasad które pozwolą na przygotowywaniu przyzwoitych commitów. Napisałem przyzwoitych dlatego że nie ma złotego podręcznika który pozwoli na pisanie idealnych zmian. Jest kilka artykułów w których poruszany jest ten temat ale najczęściej dotyczy on 7 zasad które określają jak powinien wyglądać idealny opis commita. Każda sytuacja jest inna i wymaga innego podejścia ale są pewne reguły które dzięki którym stosunkowo niewielkim kosztem możemy sprawić że odczuwalnie wzrośnie komfort pracy naszej i kolegów z zespołu. Według mnie najważniejsze zasady to:

1. Single responsibility principle

Tak! dobrze widzisz, zasada ta nie dotyczy tylko kodu, można (a nawet trzeba) stosować ją również podczas tworzenia nowych commitów. Dobre commity cechuje to, że każdy z nich powinien być rozwiązaniem jednego, określonego, malutkiego problemu. Oczywiście sam znam to uczucie gdy podczas rozwiązywania wspomnianego wyżej problemu widzimy literówkę lub inną małą zmianę która aż kusi aby ja poprawić. Ja w takich przypadkach robię zmianę, ale umieszczam ją w osobnym commicie. Po co? Na wypadek gdyby ta literówka była tam specjalnie i inny projekt będzie wywoływał metodę/funkcję z literówką 😀 Nie bez powodu ten akapit pojawił się jako pierwszy, według mnie jest to najważniejsza zasada tworzenia commitów.

2. Gdy masz dużo do napisania w commit message…

…to właśnie robisz za duży commit! Sam najczęściej podsumowuję swoją pracę w jednym zdaniu. Gdy jednak naprawdę musisz umieścić sporo informacji to podziel wiadomość na tytuł oraz opis, który należy oddzielić pustą linią.

Tytuł

Ma zawierać jedno zdanie podsumowujące wykonaną pracę. Powinien zaczynać się wielką literą oraz nie powinien kończyć się kropką, sugerowana długość nie powinna przekraczać pięćdziesięciu znaków. Jest to uwarunkowane poprawnym wyświetlaniem tytułu w konsoli (-oneline) oraz w różnych narzędziach. Nie jest to „twardy” limit tylko sugestia. Jeżeli masz problem z podsumowaniem to spójrz na pierwsze zdanie w tym akapicie.

Opis

Powinien być poprzedzony pustą linią. Długość wierszy nie powinna przekraczać 72 znaków. Tak jak powyżej nie jest to „twardy” limit tylko znowu sugestia. Podobnie jak powyżej sugestia jest związana z wyświetlaniem w narzędziach i konsoli. W opisie powinna znaleźć się informacja o tym co i po co zostało zmienione.

3. Nie wysyłaj śmieciowej historii na serwer

Macie tak czasami że rozwiążecie jakiś problem, zrobicie commita a tu nagle BUM! zapomniałem dodać komentarz, zrobić zmianę w innym miejscu kodu, itp.? Zamiast robić kolejny commit o tej samej nazwie z dwójką na końcu połącz commity przed wysłaniem na serwer (interactive rebase, amend). Jeżeli chcesz cofnąć zmiany a nie wysłałeś ich jeszcze na serwer zamiast robić revert commit usuń niechcianego commita.

Podsumowanie

To tyle, tylko tyle i aż tyle. Trzy zasady które „robią robotę” w gicie. Oczywiście artykuł nie wyczerpuje wszystkich możliwości takich jak np. Conventional Commits ale chciałem opisać to co stosuje i to co działa, bez większych komplikacji i uczenia się po nocach skomplikowanych zasad. Na koniec podrzucam przykład jak tego NIE robić, jest to prawdziwa historia na produkcyjnym rozwiązaniu (oczywiście nie moja :)):

git log

Dzięki że dobrnąłeś do końca, a teraz idź i twórz same dobre commity 😉

O autorze

Niepoprawny optymista. 100 pomysłów na sekundę, wielbiciel nowych technologii, nie tylko z rodziny .Net. Często nosi przy sobie jabłko, takie nadgryzione... ;)

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Możesz używać znaczników języka HTML i ich atrybutów: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

Zamknij