Złóż commit zgodny z Conventional Commits
Conventional Commits to format wiadomości git, który zmienia chaos ("update", "fix stuff", "wip") w czytelną historię. Każdy commit zaczyna się od typu (`feat`, `fix`, `docs`, `refactor`...), opcjonalnie ma scope w nawiasach (np. `feat(auth):`), potem krótki opis. Łatwo czytać, łatwo zautomatyzować.
To narzędzie buduje wiadomość commit z formularza. Wybierasz typ z pasków (11 typów), wpisujesz krótki opis, opcjonalnie scope, body, breaking change (dodaje `!` po typie plus footer `BREAKING CHANGE:`), footery (Closes #123, Co-authored-by, Signed-off-by).
Wynik dostajesz w trzech formatach: zwykły tekst (wklejasz do edytora po `git commit`), komenda shell (`git commit -m "..."` z escapowanymi cudzysłowami), JSON (dla botów typu semantic-release).
Walidacja na żywo: krótki opis ma maks 72 znaki (twardy limit), bez kropki na końcu, czas teraźniejszy ("add" nie "added").
Jak używać
- Wybierz typ commit w górnym pasku. feat (nowa funkcja), fix (naprawa buga), docs (dokumentacja), refactor (zmiana kodu bez zmiany zachowania), perf (optymalizacja), test, build, ci, chore (drobne porządki), revert, style (formatowanie).
- Scope (opcjonalnie), co dotyka ten commit, np. `auth`, `api`, `ui`. Klikasz preset chip albo wpisujesz własny. Pojawia się w nawiasach: `feat(auth): ...`.
- Krótki opis, jedna linia, maks 72 znaki, bez kropki na końcu, czas teraźniejszy ("add login flow", nie "added login flow"). Counter pokazuje długość, ostrzega o przekroczeniu i o czasie przeszłym.
- Breaking change (Switch), włącz, jeśli ten commit psuje wsteczną kompatybilność (zmiana API, usunięcie feature, zmiana semantyki). Generator dodaje `!` po typie (`feat!:`) i footer `BREAKING CHANGE: opis`.
- Body (opcjonalnie), szczegóły. Pisz tu pełnym zdaniem dlaczego (kontekst, motywacja), nie co (to widać z diff).
- Footers (opcjonalnie), dodaj wiersze przyciskami: Closes #123 (zamyka issue), Refs #456 (powiązany issue, ale nie zamyka), Co-authored-by (drugi autor, np. po pair programming), Signed-off-by (DCO, Developer Certificate of Origin, wymagane w niektórych projektach jak Linux kernel), Reviewed-by, Custom (własny klucz).
- Wybierz format wyjścia (Zwykły / Shell / JSON) i skopiuj. Zwykły wklejasz do edytora git po `git commit`. Shell wklejasz w terminal. JSON wrzucasz do bota CI / generatora changelog.
Do czego się przydaje
Konkretne sytuacje, w których Conventional Commits zmienia jakość projektu:
- Automatyczne wystawianie release'ów. semantic-release albo release-please analizują commity od ostatniej wersji. feat → bump minor (1.4.0 → 1.5.0). fix → bump patch (1.4.0 → 1.4.1). BREAKING CHANGE → bump major (1.4.0 → 2.0.0). Zero ręcznej pracy.
- Automatyczny CHANGELOG.md. Po release'ie narzędzie samo generuje sekcję "What's new in 1.5.0" pogrupowaną na "Features", "Bug Fixes", "Performance Improvements". Każda linia ma link do commita. Możesz to też zrobić ręcznie naszym generatorem changelog.
- Czytelna historia git. `git log --oneline` pokazuje "feat(auth): add magic link login", "fix(api): handle empty body", "docs: clarify install steps". Zamiast "update", "fix", "wip". Każdy nowy programista w zespole rozumie historię od razu.
- Code review szybsze. Recenzent widzi po prefiksie, czy to feat (zwraca uwagę na testy, edge cases) czy refactor (zwraca uwagę na zachowanie nie powinno się zmienić). Filtruje PR-y po typie.
- PR templates i CI checks. Wiele projektów (Vercel, Astro, Next.js) ma w CI walidację, że tytuł PR-a jest Conventional Commit. Tu wygenerujesz dobry tytuł i nie zostaniesz odbity przez bot.
- Praca w zespole z monorepo. Scope w commit (`feat(web):`, `fix(api):`) pozwala zorientować się, którego pakietu/aplikacji dotyczy zmiana. W changelogach grupują się osobno.
Po wygenerowaniu serii commitów, użyj generatora CHANGELOG, który grupuje commity po typach. A jeśli budujesz README projektu, w sekcji "Contributing" warto wspomnieć o Conventional Commits, generator README ma gotowy szablon.