Sprawdzanie wiadomości commita według Conventional Commits i commitlint, wraz z podbiciem wersji
Działa w przeglądarce. Wpisane dane nie są nigdzie wysyłane. Sprawdzono 16 października 2026.Conventional commit zaczyna się od typu, opcjonalnego scope i opisu, np. "fix(api): handle empty response". Po wklejeniu wiadomości można sprawdzić ją według 12 reguł config-conventional z commitlint, zobaczyć jej części oraz wydanie, które oznacza: feat to minor, fix to patch, a zmiana niezgodna wstecz to major.
Ta strona została przetłumaczona maszynowo z angielskiego oryginału. Tłumaczenie nie zostało jeszcze sprawdzone przez człowieka, dlatego wiążąca jest wersja angielska. Przeczytaj angielski oryginał
Wklej wiadomość commita albo dotknij typu, np. feat lub fix, aby zacząć nową.
Przeczytaj wynik: każdą złamaną regułę prostymi słowami oraz części, na które podzielono wiadomość.
Poprawiaj wiadomość, aż przejdzie; wiersz wydania pokazuje, czy oznacza wersję major, minor czy patch.
Dla całego pull requesta przełącz na Lista nagłówków i wklej wynik git log --format=%s.
Conventional Commits to niewielki format wiadomości commitów czytelny dla narzędzi: narzędzia do wydań wybierają na jego podstawie kolejny numer wersji, a narzędzia do changelogów zamieniają go w informacje o wydaniu. Wiele zespołów wymusza go za pomocą commitlint w hooku commit-msg, a odrzucona wiadomość commita to częsta drobna frustracja.
Format. Nagłówek, a po nim opcjonalna treść i stopki, każda część oddzielona pustym wierszem:
| Część | Przykład | Reguła |
|---|---|---|
| Typ | feat, fix, docs |
Jeden z 11, małymi literami |
| Scope | (api) |
Opcjonalny, w nawiasie |
| Zmiana niezgodna | ! przed dwukropkiem |
Albo stopka BREAKING CHANGE |
| Opis | add login page |
Mała pierwsza litera, bez kropki na końcu |
| Długość nagłówka | Najwyżej 100 znaków | |
| Stopka | Closes #123 |
Po pustym wierszu |
Co jest sprawdzane. Dwanaście reguł @commitlint/config-conventional: dziesięć błędów (pusty typ, wielkość liter typu, lista typów, pusty opis, wielkość liter opisu, kropka na końcu, długość nagłówka, spacje w nagłówku, długość wierszy treści i stopki) oraz dwa ostrzeżenia (pusty wiersz przed treścią i przed stopką). Każde naruszenie jest wyjaśnione prostymi słowami wraz z poprawką.
Podbicie wersji. Specyfikacja przypisuje commity do wersjonowania semantycznego (Semantic Versioning): fix oznacza wydanie patch, feat wydanie minor, a każda zmiana niezgodna wstecz, oznaczona ! lub stopką BREAKING CHANGE, wydanie major. Inne typy, takie jak docs czy chore, same nie zmieniają wersji.
Cały pull request. Po przełączeniu na tryb listy należy wkleić wynik git log --format=%s main..HEAD, jeden nagłówek w wierszu. Każdy nagłówek przechodzi lub nie, a łączne wydanie zostaje podane.
Wyniki porównano z @commitlint/lint 19 i config-conventional na ponad 100 wiadomościach. Wszystko działa w przeglądarce; nic, co zostanie wpisane, nie jest nigdzie wysyłane.
Wiadomość commita, której pierwszy wiersz to typ, opcjonalny scope w nawiasie, dwukropek, spacja i krótki opis, np. fix(api): handle empty response. Format pochodzi ze specyfikacji Conventional Commits 1.0.0, a narzędzia używają go do automatycznego wyboru kolejnego numeru wersji i pisania changelogów.
feat służy do zmiany, którą użytkownicy widzą jako nową możliwość, fix do poprawki błędu, a chore do prac utrzymaniowych, które nie zmieniają żadnego z nich, np. aktualizacji zależności. Wydania wynikają z nich: feat daje wersję minor, fix patch, a chore sam nie daje wydania. docs, style, refactor, perf, test, build i ci to pozostałe standardowe typy.
Należy postawić wykrzyknik przed dwukropkiem, jak w feat(api)!: remove the v1 endpoints, albo dodać po pustym wierszu stopkę zaczynającą się od BREAKING CHANGE: z opisem tego, co przestaje działać. Każdy z tych sposobów czyni wydanie wersją major, niezależnie od typu. Oba naraz są dozwolone i częste.
Zwykle dlatego, że nagłówek nie pasuje dokładnie do type: description, więc commitlint nie znajduje ani typu, ani opisu. Częste przyczyny to brak spacji po dwukropku, spacja przed nim, typ wielką literą lub nieznany albo brak typu. Wiadomość można wkleić tutaj, aby zobaczyć, która część została źle odczytana.
Nie w config-conventional: jego reguła subject-case odrzuca opisy w sentence case, start case, pascal case lub upper case, więc Add login nie przechodzi, a add login przechodzi. Tekst w odwrotnych apostrofach lub cudzysłowach jest przez tę regułę pomijany, więc nazwa taka jak `Button` na początku jest w porządku. Zespoły, które chcą wielkich liter, zmieniają regułę we własnej konfiguracji.
Nie. Domyślnie commitlint pomija commity merge, reverty utworzone przez git, commity fixup! i squash! oraz nagłówki będące samym numerem wersji, np. 1.2.3 lub chore(release): 1.2.3. Ta strona pomija te same wiadomości i o tym informuje, więc sprawdzenie tutaj daje ten sam wynik co hook.
Stawki i przepisy się zmieniają; przed oparciem się na danej liczbie należy sprawdzić źródło.
Nadal coś nie działa? Zapytaj o narzędzie Walidator Conventional Commits a odpowiedzieć może każdy, kto zna odpowiedź. Konto nie jest potrzebne.