Jak zwykle commitujesz kod?

Używam sformalizowanego formatu commitów, często opartego na Conventional Commits. Zapewnia to spójność i automatyzację niektórych procesów, takich jak generowanie dziennika zmian.

Typowy format commita:

<typ>[(obszar)]: <opis>

[<treść>]

[<notatka>]

• <typ>: Obowiązkowe. Określa typ zmian (np. feat dla nowych funkcji, fix dla poprawek, docs dla zmian w dokumentacji, style dla formatowania, refactor dla refaktoryzacji, test dla dodania testów, ci dla zmian w CI/CD).
• (obszar): Opcjonalne. Wskazuje obszar aplikacji, na który wpływają zmiany (np. (komponent: przycisk), (serwis: uwierzytelnianie)).
• <opis>: Obowiązkowe. Krótki i precyzyjny opis zmian w trybie rozkazującym (np. "dodaj przycisk", "napraw błąd walidacji").
• <treść>: Opcjonalne. Bardziej szczegółowe wyjaśnienie zmian, przyczyn i kontekstu. Oddzielone pustą linią od opisu.
• <notatka>: Opcjonalne. Zazwyczaj służy do wskazania BREAKING CHANGE z opisem, dlaczego zmiana łamie kompatybilność wsteczną, lub linkami do zadań (np. Closes #123).

Przykłady:

feat: dodaj komponent okna modalnego

fix(walidacja): napraw błąd walidacji email w formularzu rejestracyjnym

Teraz email jest poprawnie walidowany zgodnie ze standardem RFC 5322.

Closes #45

refactor(komponent: przycisk): zaktualizuj style i popraw dostępność

Refaktoryzacja stylów przycisku, aby spełniał system projektowania.
Poprawiono dostępność poprzez dodanie atrybutów ARIA.

To pomaga zespołowi lepiej rozumieć historię zmian, przyspiesza przegląd kodu i upraszcza procesy automatyczne.