mirror of
https://github.com/conventional-commits/conventionalcommits.org.git
synced 2024-11-15 02:45:15 +01:00
feat(lang): added polish language (#20)
This commit is contained in:
Morishiri
Benjamin E. Coe
parent
2865b7c42e
commit
14bfa2d075
@ -5,6 +5,7 @@ descriptions: open-source maintainer, squash feature branches onto `master` and
|
||||
# <machine readable key>: <human readable label>
|
||||
languages:
|
||||
en: english
|
||||
pl: polish
|
||||
|
||||
versions:
|
||||
- 1.0.0-beta
|
||||
|
||||
161
lang/pl/index.md
Normal file
161
lang/pl/index.md
Normal file
@ -0,0 +1,161 @@
|
||||
---
|
||||
title: Konwencjonalne Wiadomości 1.0.0-beta.1
|
||||
language: pl
|
||||
---
|
||||
|
||||
# Konwencjonalne Wiadomości 1.0.0-beta.1
|
||||
|
||||
## Streszczenie
|
||||
|
||||
Jako opiekun otwartych źródeł, spłaszczaj gałęzie funkcyjne (featurowe) do gałęzi głównej - `master`
|
||||
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).
|
||||
2. **feat:** dostarczenie _typu_ `feat` wprowadza nowe funkcje do Twojej biblioteki (powiązane z [`MINOR`](http://semver.org/#summary) w wersjonowaniu semantycznym).
|
||||
3. **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_.
|
||||
|
||||
<br />
|
||||
Przy typie dostarczenia może zostać podany zakres w celu dostarczenia dokładniejszej informacji o kontekście dostarczenia.
|
||||
Zawiera się on w nawiasach następujących bezpośrednio po typie, np. `feat(parser): dodano możliwość parsowania list`.
|
||||
|
||||
Wiadomości _typu_ innego niż `fix:` oraz `feat:` są dopuszczalne, na przykład [konwencja Angulara](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit) poleca `docs:`, `style:`, `refactor:`, `perf:`, `test:`, `chore:`,
|
||||
jednak tagi te nie są respektowane przez specyfikacje konwencjonalnych wiadomości.
|
||||
|
||||
## Wprowadzenie
|
||||
|
||||
Podczas rozwoju oprogramowania zauważyłem, że błędy często występują na granicy
|
||||
pomiędzy aplikacjami. Testy jednostkowe doskonale zdają egzamin w przypadkach, o których
|
||||
opiekun biblioteki pomyślał, jednak sposoby, w jakich oprogramowanie zostanie użyte
|
||||
przez społeczność często, choć interesujące mogą być nie do pomyślenia.
|
||||
Tutaj testy jednostkowe niezbyt zdają egzamin.
|
||||
|
||||
Każdy, kto kiedykolwiek zaktualizował zależność swojej aplikacji, chociażby o jedną wersję _patch_,
|
||||
tylko po to, aby zobaczyć, jak jego aplikacja zaczyna rzucać 500 błędami, wie,
|
||||
jak ważną rolę stanowi czytelna historia dostarczeń (oraz dodatkowo [dobrze zarządzany DZIENNIK ZMIAN](http://keepachangelog.com/en/0.3.0/))
|
||||
podczas naprawy.
|
||||
|
||||
Specyfikacja Konwencjonalnych Wiadomości proponuje wprowadzenie ustandaryzowanej, lekkiej
|
||||
konwencji wykorzystującej wiadomości w dostarczeniach. Konwencja ta łączy się z [SemVer](http://semver.org),
|
||||
nakazując deweloperom opisywanie w wiadomościach podczas dostarczania jakie funkcje wprowadzają, co naprawiają
|
||||
oraz jakie niekompatybilne wstecz zmiany wnoszą.
|
||||
|
||||
Wprowadzając tę konwencję, tworzymy powszechny język, który pozwala na dużo łatwiejsze
|
||||
wyłapywanie błędów występujących na granicy projektu z jego zależnościami.
|
||||
|
||||
## Specyfikacja Konwencjonalnych Wiadomości
|
||||
|
||||
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. dostarczenie MUSI być poprzedzone typem, który składa się z rzeczownika, np. `feat`, `fix`, itp.,
|
||||
oraz następującymi bezpośrednio po nim dwukropka oraz spacji.
|
||||
2. typ `feat` MUSI być użyt, gdy dostarczenie dodaje nową funkcję do Twojej aplikacji bądź bibliteki.
|
||||
3. typ `fix` MUSI być użyty, kiedy dostarczenie naprawia błąd w Twojej aplikacji.
|
||||
4. opcjonalny zakres MOŻE być podany po typie. Zakres jest to fraza opisująca obszar kodu zawarta w nawiasach okrągłych, np., `fix(parser):`
|
||||
5. Opis MUSI występować zaraz po przedrostku typu/zakresu.
|
||||
Opis jest to krótka notka stanowiąca o treści dostarczenia, np.,
|
||||
_fix: problem podczas parsowania listy, kiedy string zawierał wiele spacji._
|
||||
6. Dłuższe ciało wiadomośći MOŻĘ być podane po krótkim opisie. Ciało MUSI zaczynać się jedną pustą linię po opisie.
|
||||
7. 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ąznuje, np. `fixes #13, #5`.
|
||||
8. Zmiany niekompatybilne wstecz MUSZĄ być zaznaczone na samym początku sekcji ciała wiadmości lub stopki. Informacja o niekompatybilności MUSI zawierać tekst `BREAKING CHANGE`, wraz z następującymi po nim dwukropkiem oraz spacją.
|
||||
9. 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,
|
||||
np. _BREAKING CHANGE: zmienne środowiskowe mają teraz większy priorytet niż pliki konfiuguracyjne._
|
||||
10. typu inne niż `feat` oraz `fix` MOGĄ być użyte w wiadomościach Twoich dostarczeń.
|
||||
|
||||
## Dlaczego używać Konwencjonalnych Wiadomości
|
||||
|
||||
* Automatycznie generowany DZIENNIK ZMIAN.
|
||||
* Automatycznie wykrywana zmiana semantycznej zmiany wersji (określana na podstawie typów dostarczonych zmian)
|
||||
* Komunikowanie zmian członkom zespołu, publice, oraz innym zainteresowanym.
|
||||
* Wyzywalanie procesów budowania oraz publikacji.
|
||||
* Łatwiejsze włączenie się w rozwój kodu przez ludzi z zewnątrz poprzez pozwolenie im na przeglądanie
|
||||
bardziej zorganizowanej historii dostarczeń.
|
||||
|
||||
## FAQ
|
||||
|
||||
### Jak powinienem radzić sobie z wiadomościami dostarczeń w fazie początkowej rozwoju kodu?
|
||||
|
||||
Polecamy, żebyś postępował tak, jakby Twój produkt już został wydany. Zazwyczaj *ktoś*, nawet jeśli jest to Twój kolega z zespołu, już
|
||||
używa Twojego oprogramowania. Będzie chciał wiedzieć, co zostało naprawione, co nie działa itp.
|
||||
|
||||
### Co powinienem zrobić, jeśli dostarczenie pasuje do więcej niż jednego typu?
|
||||
|
||||
Wróć się i stwórz więcej dostarczeń, jeśli to tylko możliwe. Częściową korzyścią z Konwencjonalnych Wiadomości jest zdolność do tworzenia kodu
|
||||
w bardziej zorganizowany sposób.
|
||||
|
||||
### Czy takie podejście nie zniechęca do szybkiego rozwoju oraz szybkich iteracji?
|
||||
|
||||
Zniechęca do szybkiego poruszania się do przodu w niezorganizowany sposób. Pozwala Ci na szybkie posuwanie się do przodu w wielu projektach oraz
|
||||
różnorodnych deweloperów.
|
||||
|
||||
### Czy Konwencjonalne Wiadomości mogą prowadzić do zmniejszenia ilości typów dostarczanych przez deweloperów, ponieważ będą myśleć w przestrzeni wymienionych typów?
|
||||
|
||||
Konwencjonalne Wiadomości zachęcają do tworzenia większej ilości dostarczeń danego typu, np. napraw. Z innego punktu widzenia, elastyczność
|
||||
Konwencjonalnych Wiadomości pozwala Twojemu zespołowi stworzyć własne typy oraz zmieniać je z biegiem czasu.
|
||||
|
||||
### Jak jest to powiązane z SemVer?
|
||||
|
||||
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`.
|
||||
|
||||
### Jak powinienem wersjonować moje rozszerzenia zgodnie ze specyfikacją Konwencjonalnych Wiadomości, np. `@jameswomack/conventional-commit-spec`?
|
||||
|
||||
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`
|
||||
|
||||
W najgorszym przypadku - to nie koniec świata, jeśli dostarczenie niespełniające specyfikacji Konwencjonalnych Wiadomości zostanie wprowadzone.
|
||||
Po prostu znaczy to, że będzie pominięty przez narzędzia bazujące na specyfikacji.
|
||||
|
||||
### Czy wszyscy moi kontrybutorzy muszą używać specyfikacji Konwencjonalnych Wiadomości?
|
||||
|
||||
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ą.
|
||||
|
||||
## O twórcy
|
||||
|
||||
Specyfikacja Konwencjonalnych Wiadomości jest inspirowana oraz mocno bazuje na [Wytycznych Wiadomości Angulara](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit).
|
||||
|
||||
Pierwsza wersja tej specyfikacji została stworzona we współpracy z kilkoma kontrybutorami takich projektów jak:
|
||||
|
||||
* [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog): zbiór narzędzi
|
||||
pozwalających na parsowanie konwencjonalnych wiadomości z historii `git`owych dostarczeń.
|
||||
* [unleash](https://github.com/netflix/unleash): narzędzie do automatyzacji wydawania oraz publikowania.
|
||||
* [lerna](https://github.com/lerna/lerna): narzędzie do zarządzania mono-repozytoriami, które wyrosło z projektu Babel.
|
||||
|
||||
## Projekty używające Konwencjonalnych Wiadomości
|
||||
|
||||
* [yargs](https://github.com/yargs/yargs): uwielbiany przez wszystkich, piracko stylizowany parser argumentów linii komend.
|
||||
* [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 Wiadomości.
|
||||
|
||||
[](https://conventionalcommits.org)
|
||||
|
||||
_chcesz, aby Twój projekt znajdował się na tej liście?_ [stwórz prośbę o wciągnięcie](https://github.com/conventional-changelog/conventionalcommits.org/pulls).
|
||||
|
||||
## Licencja
|
||||
|
||||
[Creative Commons - CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)
|
||||
161
lang/pl/spec/v1.0.0-beta.1.md
Normal file
161
lang/pl/spec/v1.0.0-beta.1.md
Normal file
@ -0,0 +1,161 @@
|
||||
---
|
||||
title: Konwencjonalne Wiadomości 1.0.0-beta.1
|
||||
language: pl
|
||||
---
|
||||
|
||||
# Konwencjonalne Wiadomości 1.0.0-beta.1
|
||||
|
||||
## Streszczenie
|
||||
|
||||
Jako opiekun otwartych źródeł, spłaszczaj gałęzie funkcyjne (featurowe) do gałęzi głównej - `master`
|
||||
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).
|
||||
2. **feat:** dostarczenie _typu_ `feat` wprowadza nowe funkcje do Twojej biblioteki (powiązane z [`MINOR`](http://semver.org/#summary) w wersjonowaniu semantycznym).
|
||||
3. **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_.
|
||||
|
||||
<br />
|
||||
Przy typie dostarczenia może zostać podany zakres w celu dostarczenia dokładniejszej informacji o kontekście dostarczenia.
|
||||
Zawiera się on w nawiasach następujących bezpośrednio po typie, np. `feat(parser): dodano możliwość parsowania list`.
|
||||
|
||||
Wiadomości _typu_ innego niż `fix:` oraz `feat:` są dopuszczalne, na przykład [konwencja Angulara](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit) poleca `docs:`, `style:`, `refactor:`, `perf:`, `test:`, `chore:`,
|
||||
jednak tagi te nie są respektowane przez specyfikacje konwencjonalnych wiadomości.
|
||||
|
||||
## Wprowadzenie
|
||||
|
||||
Podczas rozwoju oprogramowania zauważyłem, że błędy często występują na granicy
|
||||
pomiędzy aplikacjami. Testy jednostkowe doskonale zdają egzamin w przypadkach, o których
|
||||
opiekun biblioteki pomyślał, jednak sposoby, w jakich oprogramowanie zostanie użyte
|
||||
przez społeczność często, choć interesujące mogą być nie do pomyślenia.
|
||||
Tutaj testy jednostkowe niezbyt zdają egzamin.
|
||||
|
||||
Każdy, kto kiedykolwiek zaktualizował zależność swojej aplikacji, chociażby o jedną wersję _patch_,
|
||||
tylko po to, aby zobaczyć, jak jego aplikacja zaczyna rzucać 500 błędami, wie,
|
||||
jak ważną rolę stanowi czytelna historia dostarczeń (oraz dodatkowo [dobrze zarządzany DZIENNIK ZMIAN](http://keepachangelog.com/en/0.3.0/))
|
||||
podczas naprawy.
|
||||
|
||||
Specyfikacja Konwencjonalnych Wiadomości proponuje wprowadzenie ustandaryzowanej, lekkiej
|
||||
konwencji wykorzystującej wiadomości w dostarczeniach. Konwencja ta łączy się z [SemVer](http://semver.org),
|
||||
nakazując deweloperom opisywanie w wiadomościach podczas dostarczania jakie funkcje wprowadzają, co naprawiają
|
||||
oraz jakie niekompatybilne wstecz zmiany wnoszą.
|
||||
|
||||
Wprowadzając tę konwencję, tworzymy powszechny język, który pozwala na dużo łatwiejsze
|
||||
wyłapywanie błędów występujących na granicy projektu z jego zależnościami.
|
||||
|
||||
## Specyfikacja Konwencjonalnych Wiadomości
|
||||
|
||||
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. dostarczenie MUSI być poprzedzone typem, który składa się z rzeczownika, np. `feat`, `fix`, itp.,
|
||||
oraz następującymi bezpośrednio po nim dwukropka oraz spacji.
|
||||
2. typ `feat` MUSI być użyt, gdy dostarczenie dodaje nową funkcję do Twojej aplikacji bądź bibliteki.
|
||||
3. typ `fix` MUSI być użyty, kiedy dostarczenie naprawia błąd w Twojej aplikacji.
|
||||
4. opcjonalny zakres MOŻE być podany po typie. Zakres jest to fraza opisująca obszar kodu zawarta w nawiasach okrągłych, np., `fix(parser):`
|
||||
5. Opis MUSI występować zaraz po przedrostku typu/zakresu.
|
||||
Opis jest to krótka notka stanowiąca o treści dostarczenia, np.,
|
||||
_fix: problem podczas parsowania listy, kiedy string zawierał wiele spacji._
|
||||
6. Dłuższe ciało wiadomośći MOŻĘ być podane po krótkim opisie. Ciało MUSI zaczynać się jedną pustą linię po opisie.
|
||||
7. 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ąznuje, np. `fixes #13, #5`.
|
||||
8. Zmiany niekompatybilne wstecz MUSZĄ być zaznaczone na samym początku sekcji ciała wiadmości lub stopki. Informacja o niekompatybilności MUSI zawierać tekst `BREAKING CHANGE`, wraz z następującymi po nim dwukropkiem oraz spacją.
|
||||
9. 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,
|
||||
np. _BREAKING CHANGE: zmienne środowiskowe mają teraz większy priorytet niż pliki konfiuguracyjne._
|
||||
10. typu inne niż `feat` oraz `fix` MOGĄ być użyte w wiadomościach Twoich dostarczeń.
|
||||
|
||||
## Dlaczego używać Konwencjonalnych Wiadomości
|
||||
|
||||
* Automatycznie generowany DZIENNIK ZMIAN.
|
||||
* Automatycznie wykrywana zmiana semantycznej zmiany wersji (określana na podstawie typów dostarczonych zmian)
|
||||
* Komunikowanie zmian członkom zespołu, publice, oraz innym zainteresowanym.
|
||||
* Wyzywalanie procesów budowania oraz publikacji.
|
||||
* Łatwiejsze włączenie się w rozwój kodu przez ludzi z zewnątrz poprzez pozwolenie im na przeglądanie
|
||||
bardziej zorganizowanej historii dostarczeń.
|
||||
|
||||
## FAQ
|
||||
|
||||
### Jak powinienem radzić sobie z wiadomościami dostarczeń w fazie początkowej rozwoju kodu?
|
||||
|
||||
Polecamy, żebyś postępował tak, jakby Twój produkt już został wydany. Zazwyczaj *ktoś*, nawet jeśli jest to Twój kolega z zespołu, już
|
||||
używa Twojego oprogramowania. Będzie chciał wiedzieć, co zostało naprawione, co nie działa itp.
|
||||
|
||||
### Co powinienem zrobić, jeśli dostarczenie pasuje do więcej niż jednego typu?
|
||||
|
||||
Wróć się i stwórz więcej dostarczeń, jeśli to tylko możliwe. Częściową korzyścią z Konwencjonalnych Wiadomości jest zdolność do tworzenia kodu
|
||||
w bardziej zorganizowany sposób.
|
||||
|
||||
### Czy takie podejście nie zniechęca do szybkiego rozwoju oraz szybkich iteracji?
|
||||
|
||||
Zniechęca do szybkiego poruszania się do przodu w niezorganizowany sposób. Pozwala Ci na szybkie posuwanie się do przodu w wielu projektach oraz
|
||||
różnorodnych deweloperów.
|
||||
|
||||
### Czy Konwencjonalne Wiadomości mogą prowadzić do zmniejszenia ilości typów dostarczanych przez deweloperów, ponieważ będą myśleć w przestrzeni wymienionych typów?
|
||||
|
||||
Konwencjonalne Wiadomości zachęcają do tworzenia większej ilości dostarczeń danego typu, np. napraw. Z innego punktu widzenia, elastyczność
|
||||
Konwencjonalnych Wiadomości pozwala Twojemu zespołowi stworzyć własne typy oraz zmieniać je z biegiem czasu.
|
||||
|
||||
### Jak jest to powiązane z SemVer?
|
||||
|
||||
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`.
|
||||
|
||||
### Jak powinienem wersjonować moje rozszerzenia zgodnie ze specyfikacją Konwencjonalnych Wiadomości, np. `@jameswomack/conventional-commit-spec`?
|
||||
|
||||
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`
|
||||
|
||||
W najgorszym przypadku - to nie koniec świata, jeśli dostarczenie niespełniające specyfikacji Konwencjonalnych Wiadomości zostanie wprowadzone.
|
||||
Po prostu znaczy to, że będzie pominięty przez narzędzia bazujące na specyfikacji.
|
||||
|
||||
### Czy wszyscy moi kontrybutorzy muszą używać specyfikacji Konwencjonalnych Wiadomości?
|
||||
|
||||
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ą.
|
||||
|
||||
## O twórcy
|
||||
|
||||
Specyfikacja Konwencjonalnych Wiadomości jest inspirowana oraz mocno bazuje na [Wytycznych Wiadomości Angulara](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit).
|
||||
|
||||
Pierwsza wersja tej specyfikacji została stworzona we współpracy z kilkoma kontrybutorami takich projektów jak:
|
||||
|
||||
* [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog): zbiór narzędzi
|
||||
pozwalających na parsowanie konwencjonalnych wiadomości z historii `git`owych dostarczeń.
|
||||
* [unleash](https://github.com/netflix/unleash): narzędzie do automatyzacji wydawania oraz publikowania.
|
||||
* [lerna](https://github.com/lerna/lerna): narzędzie do zarządzania mono-repozytoriami, które wyrosło z projektu Babel.
|
||||
|
||||
## Projekty używające Konwencjonalnych Wiadomości
|
||||
|
||||
* [yargs](https://github.com/yargs/yargs): uwielbiany przez wszystkich, piracko stylizowany parser argumentów linii komend.
|
||||
* [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 Wiadomości.
|
||||
|
||||
[](https://conventionalcommits.org)
|
||||
|
||||
_chcesz, aby Twój projekt znajdował się na tej liście?_ [stwórz prośbę o wciągnięcie](https://github.com/conventional-changelog/conventionalcommits.org/pulls).
|
||||
|
||||
## Licencja
|
||||
|
||||
[Creative Commons - CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)
|
||||
160
lang/pl/spec/v1.0.0-beta.md
Normal file
160
lang/pl/spec/v1.0.0-beta.md
Normal file
@ -0,0 +1,160 @@
|
||||
---
|
||||
title: Konwencjonalne Wiadomości 1.0.0-beta
|
||||
language: pl
|
||||
---
|
||||
|
||||
# Konwencjonalne Wiadomości 1.0.0-beta
|
||||
|
||||
## Streszczenie
|
||||
|
||||
Jako opiekun otwartych źródeł, spłaszczaj gałęzie funkcyjne (featurowe) do gałęzi głównej - `master`
|
||||
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).
|
||||
2. **feat:** dostarczenie _typu_ `feat` wprowadza nowe funkcje do Twojej biblioteki (powiązane z [`MINOR`](http://semver.org/#summary) w wersjonowaniu semantycznym).
|
||||
3. **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 _typu_, `fix:` lub `feat:`.
|
||||
<br />
|
||||
Przy typie dostarczenia może zostać podany zakres w celu dostarczenia dokładniejszej informacji o kontekście dostarczenia.
|
||||
Zawiera się on w nawiasach następujących bezpośrednio po typie, np. `feat(parser): dodano możliwość parsowania list`.
|
||||
|
||||
Wiadomości _typu_ innego niż `fix:` oraz `feat:` są dopuszczalne, na przykład [konwencja Angulara](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit) poleca `docs:`, `style:`, `refactor:`, `perf:`, `test:`, `chore:`,
|
||||
jednak tagi te nie są respektowane przez specyfikacje konwencjonalnych wiadomości.
|
||||
|
||||
## Wprowadzenie
|
||||
|
||||
Podczas rozwoju oprogramowania zauważyłem, że błędy często występują na granicy
|
||||
pomiędzy aplikacjami. Testy jednostkowe doskonale zdają egzamin w przypadkach, o których
|
||||
opiekun biblioteki pomyślał, jednak sposoby, w jakich oprogramowanie zostanie użyte
|
||||
przez społeczność często, choć interesujące mogą być nie do pomyślenia.
|
||||
Tutaj testy jednostkowe niezbyt zdają egzamin.
|
||||
|
||||
Każdy, kto kiedykolwiek zaktualizował zależność swojej aplikacji, chociażby o jedną wersję _patch_,
|
||||
tylko po to, aby zobaczyć, jak jego aplikacja zaczyna rzucać 500 błędami, wie,
|
||||
jak ważną rolę stanowi czytelna historia dostarczeń (oraz dodatkowo [dobrze zarządzany DZIENNIK ZMIAN](http://keepachangelog.com/en/0.3.0/))
|
||||
podczas naprawy.
|
||||
|
||||
Specyfikacja Konwencjonalnych Wiadomości proponuje wprowadzenie ustandaryzowanej, lekkiej
|
||||
konwencji wykorzystującej wiadomości w dostarczeniach. Konwencja ta łączy się z [SemVer](http://semver.org),
|
||||
nakazując deweloperom opisywanie w wiadomościach podczas dostarczania jakie funkcje wprowadzają, co naprawiają
|
||||
oraz jakie niekompatybilne wstecz zmiany wnoszą.
|
||||
|
||||
Wprowadzając tę konwencję, tworzymy powszechny język, który pozwala na dużo łatwiejsze
|
||||
wyłapywanie błędów występujących na granicy projektu z jego zależnościami.
|
||||
|
||||
## Specyfikacja Konwencjonalnych Wiadomości
|
||||
|
||||
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. dostarczenie MUSI być poprzedzone typem, który składa się z rzeczownika, np. `feat`, `fix`, itp.,
|
||||
oraz następującymi bezpośrednio po nim dwukropka oraz spacji.
|
||||
2. typ `feat` MUSI być użyt, gdy dostarczenie dodaje nową funkcję do Twojej aplikacji bądź bibliteki.
|
||||
3. typ `fix` MUSI być użyty, kiedy dostarczenie naprawia błąd w Twojej aplikacji.
|
||||
4. opcjonalny zakres MOŻE być podany po typie. Zakres jest to fraza opisująca obszar kodu zawarta w nawiasach okrągłych, np., `fix(parser):`
|
||||
5. Opis MUSI występować zaraz po przedrostku typu/zakresu.
|
||||
Opis jest to krótka notka stanowiąca o treści dostarczenia, np.,
|
||||
_fix: problem podczas parsowania listy, kiedy string zawierał wiele spacji._
|
||||
6. Dłuższe ciało wiadomośći MOŻĘ być podane po krótkim opisie. Ciało MUSI zaczynać się jedną pustą linię po opisie.
|
||||
7. 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ąznuje, np. `fixes #13, #5`.
|
||||
8. Zmiany niekompatybilne wstecz MUSZĄ być zaznaczone na samym początku sekcji ciała wiadmości lub stopki. Informacja o niekompatybilności MUSI zawierać tekst `BREAKING CHANGE`, wraz z następującymi po nim dwukropkiem oraz spacją.
|
||||
9. 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,
|
||||
np. _BREAKING CHANGE: zmienne środowiskowe mają teraz większy priorytet niż pliki konfiuguracyjne._
|
||||
10. typu inne niż `feat` oraz `fix` MOGĄ być użyte w wiadomościach Twoich dostarczeń.
|
||||
|
||||
## Dlaczego używać Konwencjonalnych Wiadomości
|
||||
|
||||
* Automatycznie generowany DZIENNIK ZMIAN.
|
||||
* Automatycznie wykrywana zmiana semantycznej zmiany wersji (określana na podstawie typów dostarczonych zmian)
|
||||
* Komunikowanie zmian członkom zespołu, publice, oraz innym zainteresowanym.
|
||||
* Wyzywalanie procesów budowania oraz publikacji.
|
||||
* Łatwiejsze włączenie się w rozwój kodu przez ludzi z zewnątrz poprzez pozwolenie im na przeglądanie
|
||||
bardziej zorganizowanej historii dostarczeń.
|
||||
|
||||
## FAQ
|
||||
|
||||
### Jak powinienem radzić sobie z wiadomościami dostarczeń w fazie początkowej rozwoju kodu?
|
||||
|
||||
Polecamy, żebyś postępował tak, jakby Twój produkt już został wydany. Zazwyczaj *ktoś*, nawet jeśli jest to Twój kolega z zespołu, już
|
||||
używa Twojego oprogramowania. Będzie chciał wiedzieć, co zostało naprawione, co nie działa itp.
|
||||
|
||||
### Co powinienem zrobić, jeśli dostarczenie pasuje do więcej niż jednego typu?
|
||||
|
||||
Wróć się i stwórz więcej dostarczeń, jeśli to tylko możliwe. Częściową korzyścią z Konwencjonalnych Wiadomości jest zdolność do tworzenia kodu
|
||||
w bardziej zorganizowany sposób.
|
||||
|
||||
### Czy takie podejście nie zniechęca do szybkiego rozwoju oraz szybkich iteracji?
|
||||
|
||||
Zniechęca do szybkiego poruszania się do przodu w niezorganizowany sposób. Pozwala Ci na szybkie posuwanie się do przodu w wielu projektach oraz
|
||||
różnorodnych deweloperów.
|
||||
|
||||
### Czy Konwencjonalne Wiadomości mogą prowadzić do zmniejszenia ilości typów dostarczanych przez deweloperów, ponieważ będą myśleć w przestrzeni wymienionych typów?
|
||||
|
||||
Konwencjonalne Wiadomości zachęcają do tworzenia większej ilości dostarczeń danego typu, np. napraw. Z innego punktu widzenia, elastyczność
|
||||
Konwencjonalnych Wiadomości pozwala Twojemu zespołowi stworzyć własne typy oraz zmieniać je z biegiem czasu.
|
||||
|
||||
### Jak jest to powiązane z SemVer?
|
||||
|
||||
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`.
|
||||
|
||||
### Jak powinienem wersjonować moje rozszerzenia zgodnie ze specyfikacją Konwencjonalnych Wiadomości, np. `@jameswomack/conventional-commit-spec`?
|
||||
|
||||
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`
|
||||
|
||||
W najgorszym przypadku - to nie koniec świata, jeśli dostarczenie niespełniające specyfikacji Konwencjonalnych Wiadomości zostanie wprowadzone.
|
||||
Po prostu znaczy to, że będzie pominięty przez narzędzia bazujące na specyfikacji.
|
||||
|
||||
### Czy wszyscy moi kontrybutorzy muszą używać specyfikacji Konwencjonalnych Wiadomości?
|
||||
|
||||
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ą.
|
||||
|
||||
## O twórcy
|
||||
|
||||
Specyfikacja Konwencjonalnych Wiadomości jest inspirowana oraz mocno bazuje na [Wytycznych Wiadomości Angulara](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit).
|
||||
|
||||
Pierwsza wersja tej specyfikacji została stworzona we współpracy z kilkoma kontrybutorami takich projektów jak:
|
||||
|
||||
* [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog): zbiór narzędzi
|
||||
pozwalających na parsowanie konwencjonalnych wiadomości z historii `git`owych dostarczeń.
|
||||
* [unleash](https://github.com/netflix/unleash): narzędzie do automatyzacji wydawania oraz publikowania.
|
||||
* [lerna](https://github.com/lerna/lerna): narzędzie do zarządzania mono-repozytoriami, które wyrosło z projektu Babel.
|
||||
|
||||
## Projekty używające Konwencjonalnych Wiadomości
|
||||
|
||||
* [yargs](https://github.com/yargs/yargs): uwielbiany przez wszystkich, piracko stylizowany parser argumentów linii komend.
|
||||
* [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 Wiadomości.
|
||||
|
||||
[](https://conventionalcommits.org)
|
||||
|
||||
_chcesz, aby Twój projekt znajdował się na tej liście?_ [stwórz prośbę o wciągnięcie](https://github.com/conventional-changelog/conventionalcommits.org/pulls).
|
||||
|
||||
## Licencja
|
||||
|
||||
[Creative Commons - CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)
|
||||
Loading…
Reference in New Issue
Block a user