gaspersic/freeCodeCamp
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
b6f8c7c800d6beac4fb8781af74e9fa14e48201c
freeCodeCamp/docs/i18n-languages/polish/how-to-open-a-pull-request.md
mathias3 b27d9ce770 docs(i18n): contributing guidelines in polish (#37350) 
Co-Authored-By: Cezary Waś <44169282+Qondor@users.noreply.github.com>
Co-authored-by: kassjja <52068785+kassjja@users.noreply.github.com>
2020-03-12 22:24:18 +05:30

2.7 KiB
Raw Blame History

Read these guidelines in other languages

Jak otworzyć Pull Request

Jak przygotowac dobrą nazwę Pull Request:

Przy otwieraniu Pull Request(PR), użyj poniższej tabeli, aby zdecydować, jaki tytuł ma nosić Twój PR w poniższym formacie: `fix/feat/chore/refactor/docs/perf (zakres): Tytuł PR

Przykładem jest fix(learn): Naprawiono testy dla do...while loop challenge.

Scope Documentation
learn,curriculum For Pull Requests making changes to the curriculum challenges.
client For Pull Requests making changes to client platform logic or user interface
guide For Pull Requests which make changes to the guide.
docs For Pull Requests making changes to the project's documentation.

Gdy proponuijesz Pull Request (PR)

  1. Po dokonaniu edycji zostanie wyświetlony monit o utworzenie żądania przeciągnięcia na stronie GitHub widelca.

    Obraz - Porównaj prośbę o wyciągnięcie na GitHub

  2. Domyślnie, wszystkie żądania pobrania powinny być skierowane przeciwko głównemu repo freeCodeCamp, gałęzi master.

    Upewnij się, że twój widelec bazowy jest ustawiony na freeCodeCamp/freeCodeCamp podczas podnoszenia żądania przeciągnięcia.

    Obraz - porównywanie widelców podczas składania żądania ciągnięcia

  3. Wyślij żądanie ściągnięcia z gałezi do gałęzi mastera freeCodeCamp.

  4. W treści swojego PR zamieść bardziej szczegółowe podsumowanie wprowadzonych przez Ciebie zmian i dlaczego.

    • Otrzymasz szablon wniosku o pull request. Jest to lista kontrolna, którą powinieneś był zastosować przed otwarciem pull request.

    • Wypełnij szczegóły, które wydają Ci się pasować. Informacje te zostaną zweryfikowane i zadecydują, czy wniosek o pull request zostanie przyjęty, czy też nie.

    • Jeśli PR ma na celu naprawienie istniejącego błędu/sprawy, to na końcu opis Twojego PR, dodaj słowo kluczowe zamknięciai#xxxxxx (gdzie xxxx jest numerem wydania). Przykład: zamknięcie #1337. To mówi GitHub, aby automatycznie zamyka istniejącą sprawę, jeśli PR zostanie zaakceptowany i połączony.

  5. Wskazać, czy testowałeś na lokalnej kopii strony, czy też nie.

    Jest to bardzo ważne, gdy dokonujesz zmian, które nie ograniczają się jedynie do edycji treści tekstowych, takich jak artykuł w Przewodniku. Przykłady zmian wymagających lokalnego testowania to JavaScript, CSS lub HTML, które mogą zmienić funkcjonalność lub układ strony.