oraz pisz ustandaryzowane opisy dostarczeń (commitów).
Opis dostarczenia powinien wyglądać następująco:
---
```
<typ>[opcjonalny zakres]: <opis>
[opcjonalne ciało wiadomości]
[opcjonalna stopka wiadomości]
```
---
<br/>
Wiadomość zawiera następujące strukturalne elementy po to, aby zakomunikować intencje
do użytkowników Twojej biblioteki:
1.**fix:** dostarczenie _typu_`fix` naprawia błąd obecny w Twoim kodzie (powiązane z [`PATCH`](http://semver.org/#summary) w wersjonowaniu semantycznym).
1.**feat:** dostarczenie _typu_`feat` wprowadza nowe funkcje do Twojej biblioteki (powiązane z [`MINOR`](http://semver.org/#summary) w wersjonowaniu semantycznym).
1.**BREAKING CHANGE:** dostarczenie, które posiada tekst `BREAKING CHANGE:` na początku jego opcjonalnego ciała bądź stopki wprowadza zmianę łamiącą kompatybilność API (powiązane z [`MAJOR`](http://semver.org/#summary) w wersjonowaniu semantycznym). Zmiana łamiąca kompatybilność wsteczną może być elementem zmian każdego innego _typu_, np. `fix:`, `feat:`&`chore:` - wszystkie byłyby poprawne, w dodatku do każdego innego _typu_.
1. Inne: commity _typu_ innego niż `fix:` oraz `feat:` są dozwolone, np. [commitlint-config-conventional](https://github.com/marionebl/commitlint/tree/master/%40commitlint/config-conventional) (bazowano na [konwencji Angulara](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) poleca `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, oraz inne. My polecamy także `improvement` dla dostarczeń, które ulepszają obecną implementację bez dodawania nowych funkcjonalności lub naprawy błędów. Zauważ, że te typy nie są obowiązkowe według specyfikacji konwencjonalnych commitów i nie mają wpływu na wersjonowanie (chyba, że zawierają BREAKING CHANGE, co NIE JEST rekomendowane).
jak ważną rolę stanowi czytelna historia dostarczeń (oraz dodatkowo [dobrze zarządzany DZIENNIK ZMIAN (CHANGELOG)](http://keepachangelog.com/en/0.3.0/))
Następujące terminy “MUSI” (“MUST”), “NIE MOŻE” (“MUST NOT”), “WYMAGANY” (“REQUIRED”), “MA BYĆ” (“SHALL”), “NIE BĘDZIE” (“SHALL NOT”), “POWINIEN” (“SHOULD”), “NIE POWINIEN” (“SHOULD NOT”), “ZALECANY” (“RECOMMENDED”), “MOŻE” (“MAY”) oraz “OPCJONALNY” (“OPTIONAL”) pojawiające się w tym dokumencie rozumiane są zgodnie z ich opisem na stronie: [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
1. Dłuższe ciało wiadomości MOŻE być podane po krótkim opisie. Ciało MUSI zaczynać się jedną pustą linię po opisie.
1. Stopka MOŻE być podane jedną linię za ciałem wiadomości. Stopka POWINNA zawierać dodatkowe informacje odnośnie zgłoszeń błędów lub propozycji funkcjonalności, które rozwiązuje, np. `fixes #13, #5`.
1. Zmiany niekompatybilne wstecz MUSZĄ być zaznaczone na samym początku sekcji ciała wiadomości lub stopki. Informacja o niekompatybilności MUSI zawierać tekst `BREAKING CHANGE`, wraz z następującymi po nim dwukropkiem oraz spacją.
1. Po tekście `BREAKING CHANGE: ` MUSI następować opis mówiący o tym, co zostało zmienione w kodzie w sposób, który niszczy kompatybilność wstecz,
### Czy Konwencjonalne Commity mogą prowadzić do zmniejszenia ilości typów dostarczanych przez deweloperów, ponieważ będą myśleć w przestrzeni wymienionych typów?
Wiadomości typu `fix` powinny być traktowane tak jak `PATCH`. Wiadomości typu `feat` tak jak `MINOR`, natomiast dostarczenia zawierające `BREAKING CHANGE`, bez względu na typ, powinny być traktowane jak `MAJOR`.
Zalecamy używanie SemVer do wydawania własnych rozszerzeń do tej specyfikacji (oraz zachęcamy do tworzenia tych rozszerzeń!).
### Co powinienem zrobić, jeśli przypadkowo użyje błędnego typu dostarczenia?
#### Jeśli użyłeś typu, który znajduje się w specyfikacji, ale nie jest poprawny, np. `fix` zamiast `feat`
Przed dostarczeniem i wydaniem pomyłki, polecamy użyć `git rebase -i` w celu zmienienia historii dostarczeń. Zmiana po dostarczeniu zależy od narzędzi oraz procesów, których używasz.
#### Jeśli użyłeś typu, który *nie* znajduje się w specyfikacji, np. `feet` zamiast `feat`
Nie! Jeśli używasz trybu bazującego na spłaszczaniu historii dostarczeń, wtedy główni opiekunowie projektu mogą posprzątać wiadomości
podczas dostarczania. Takie podejście nie narzuca żadnego obowiązku na osoby dostarczające od czasu do czasu. Powszechnym podejściem
jest używanie automatycznego spłaszczania historii dostarczeń z prośby wciągnięcia (pull request) oraz wyświetlenie formularza osobie dostarczającej w celu wypełnienia wiadomości poprawną treścią.
Specyfikacja Konwencjonalnych Commitów jest inspirowana oraz mocno bazuje na [Wytycznych Commitów Angulara](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit).
* [istanbuljs](https://github.com/istanbuljs/istanbuljs): kolekcja otwarto-źródłowych narzędzi oraz bibliotek do dodawania miar pokrycia kodu do Twoich testów jednostkowych
* [standard-version](https://github.com/conventional-changelog/standard-version): Automatyczne zarządzanie wersjami oraz DZIENNIKIEM ZMIAN, używający nowego przycisku Spłaszcz na GitHubie oraz trybu pracy opartego o Konwencjonalne Commity.
_chcesz, aby Twój projekt znajdował się na tej liście?_ [stwórz pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls).
