Jako programiści często musimy stawić czoła różnym wyzwaniom, a jednym z nich jest nazywanie zmiennych. Ale czy zastanawialiście się kiedyś, jak ważne jest również właściwe nazewnictwo w kontekście commitów? Początkowo miałem z tym spore problemy, ale dzięki pewnej metodzie moje commit messages stały się bardziej czytelne i zorganizowane.

1. Build: tworzenie struktury i zależności zewnętrzne

Czasami wprowadzenie zmian w systemie budowania lub zewnętrznych zależnościach może okazać się wyzwaniem. Dlatego warto zawsze oznaczać tego typu zmiany. Na przykład:

git commit -m "build: Zaktualizowano skrypty gulp dla lepszej obsługi zadań"

2. CI: konfiguracja i skrypty CI

Jeśli wprowadzacie zmiany w plikach konfiguracyjnych lub skryptach CI, pamiętajcie o odpowiednim oznaczeniu. To pozwoli z łatwością identyfikować zmiany związane z integracją ciągłą. Przykład:

git commit -m "ci: Zaktualizowano skrypty Travis do obsługi nowych wersji zależności"

Masz dosyć czytania? Obejrzyj ten filmik, w którym Michał wytłumaczy Ci to wszystko szybko i prosto.

View this post on Instagram

A post shared by Ragnarson (@ragnarsoncom)

3. Feat: nowa funkcjonalność

Nowa funkcjonalność zawsze wymaga specjalnego oznaczenia. To ułatwia śledzenie wprowadzanych usprawnień w kodzie. Przykład:

git commit -m "feat: Dodano możliwość logowania za pomocą konta Google"

4. Fix: naprawa błędów

Każda naprawa błędu powinna być jasno zaznaczona. Dzięki temu unikamy zamieszania i łatwo możemy zidentyfikować, co się poprawiło. Przykład:

git commit -m "fix: Poprawiono błąd związany z nieprawidłowym wyświetlaniem formularza logowania"

5. Docs: zmiany w dokumentacji

Zmiany w dokumentacji są równie ważne jak zmiany w kodzie. Oznaczajmy je odpowiednio, aby nie pomylić ich z innymi rodzajami commitów. Przykład:

git commit -m "docs: Zaktualizowano instrukcję obsługi dla nowych użytkowników"

6. Style: zmiany stylu i formatowania

Zmiany, które dotyczą jedynie stylu, formatowania czy białych znaków, powinny być oznaczane jako "style". Przykład:

git commit -m "style: Poprawiono wcięcia w plikach CSS"

7. Refactor: poprawki niezmieniające funkcjonalności

Jeśli wprowadzacie zmiany, które nie mają wpływu na funkcjonalność, ale poprawiają jakość kodu, użyjcie oznaczenia "refactor". Przykład:

git commit -m "refactor: Zmiana nazw zmiennych dla lepszej czytelności"

8. Perf: zmiany poprawiające wydajność

Jeżeli wprowadzacie zmiany mające na celu poprawę wydajności, oznaczajcie je jako "perf". Przykład:

git commit -m "perf: Zoptymalizowano zapytania bazodanowe dla szybszego dostępu do danych"

9. Test: zmiany w testach

Dodanie nowych testów lub poprawa istniejących powinna być oznaczana jako "test". To pomaga utrzymać porządek w strukturze projektu. Przykład:

git commit -m "test: Dodano testy jednostkowe dla klasy obsługującej logowanie użytkownika"

Wprowadzenie tej konwencji dla commit messages ułatwia życie programisty. Dzięki odpowiedniemu oznaczaniu, zarówno sam programista, jak i inni członkowie zespołu, mogą szybko zrozumieć, co dokładnie się zmieniło w kodzie. Przyczynia się to do zwiększenia czytelności historii projektu oraz ułatwia śledzenie postępów i rozwoju aplikacji.

Warto również zaznaczyć, że stosowanie tej konwencji wymaga dyscypliny i konsekwencji. Jednak, gdy już się do niej przyzwyczaimy, korzyści płynące z łatwiejszego zarządzania kodem są bezcenne.