7.3 KiB

Raw Blame History

Jak otworzyć Pull Request (PR)

Pull Request umożliwia wysyłanie zmian z forku na GitHub do głównego repozytorium FreCodeCamp.org. Po dokonaniu zmian w kodzie lub wyzwaniach w kodowaniu powinieneś postępować zgodnie z niniejszymi wytycznymi, aby wysłać PR.

Przygotuj dobry tytuł PR

Zalecamy użycie tradycyjnego tytułu i wiadomości dla poleceń i pull requesta. Konwencja ma następujący format:

<type>([opcjonalny zakres(y)]): <description>

Na przykład:

fix(learn): testy dla do...while loop challenge

Podczas otwierania Pull Request(PR) możesz użyć poniższego przycisku, aby określić typ, zakres (opcjonalnie) i opis.

Typ:

Typ	Kiedy wybrać
Napraw	Zmieniona lub zaktualizowana/udoskonalona funkcjonalność, testy, odwrotnie lekcji itp.
feat	Tylko w przypadku dodawania nowych funkcji, testów itp.
ruda	Zmiany niezwiązane z kodem, testami lub werbijaniem lekcji.
dokumenty	Zmiany w katalogu `/docs` lub wytycznych dotyczących wkładu, itp.

Zakres:

Możesz wybrać zakres z tej listy etykiet.

Opis:

Pozostaw to krótkie (mniej niż 30 znaków) i proste, możesz dodać więcej informacji w polu opisu PR i komentarze.

Przykładami dobrych tytułów PR:

fix(a11y): poprawiony kontrast paska wyszukiwania
feat: dodaj więcej testów do wyzwań html i css
fix(api, klient): zapobiegaj błędom CORS przy składaniu formularza
docs(i18n): chińskie tłumaczenie ustawień lokalnych

Propozycja Pull Request

Gdy edycje zostaną zatwierdzone, zostaniesz poproszony o utworzenie pull request na swojej stronie GitHub forka.
Domyślnie wszystkie Pull Requesty powinny być skierowane przeciwko głównemu repozytorium FreeCamp, master.

Upewnij się, że twój Fork Bazowy jest ustawiony na darmowy CodeCamp/freeCodeCamp podczas podnoszenia Pull Request.
Submit the pull request from your branch to freeCodeCamp's master branch.
W treści PR znajduje się bardziej szczegółowe podsumowanie wprowadzonych zmian i dlaczego.
- Zostaniesz zaprezentowany z szablonem Pull Request. To jest lista kontrolna, którą powinieneś był obserwować przed otwarciem pull requesta.
- Wypełnij szczegóły zgodnie z tym, co uważasz. Informacje te zostaną sprawdzone, a recenzenci zdecydują, czy Pull Request jest zaakceptowany.
- Jeśli PR ma zająć się istniejącym problemem GitHub, wtedy pod koniec treści opisu PR, użyj słowa kluczowego Zamyka z numerem zgłoszenia, aby automatycznie zamknąć ten problem, jeśli PR jest akceptowany i scalony.
  
  Przykład: Zamyka #123 zamknie problem 123
Wskaż, czy przetestowałeś lokalną kopię witryny.

Jest to bardzo ważne podczas wprowadzania zmian, które nie są tylko edytowane do treści tekstowych, takich jak dokumentacja lub opis wyzwania. Przykłady zmian, które wymagają lokalnych testów, to JavaScript, CSS lub HTML, które mogą zmienić funkcjonalność lub układ strony.

Opinie na temat pull requestów

Gratulacje! 🎉 za wypełnienie PR i bardzo dziękuję za poświęcenie czasu na wniesienie wkładu.

Nasi moderatorzy teraz spojrzą na Ciebie i zostawią Ci opinię. Proszę być cierpliwy z innymi moderatorami i szanować ich czas. Wszystkie Pull Requesty są sprawdzane w odpowiednim czasie.

Jeśli potrzebujesz jakiejkolwiek pomocy, prosimy o omówienie w rozmowach na czacie, z przyjemnością Ci pomożemy.

[!Wskazówka] Jeśli chcesz wnieść więcej pull requestów, zalecamy przeczytanie wprowadzanie zmian i synchronizację wytycznych, aby uniknąć konieczności usuwania forku.

Konflikt na pull request

Konflikty mogą powstać, ponieważ wielu współtwórców pracuje w repozytorium, a zmiany mogą przerwać Twój PR, który oczekuje na przegląd i połączenie.

Najczęściej niż nie potrzebujesz bazy danych, ponieważ zniszczymy wszystkie zobowiązania, jednakże jeśli prośba o rebazę jest tutaj o to, co powinieneś zrobić.

Dla zwykłych poprawek błędów i funkcji

Gdy pracujesz nad zwykłymi błędami i funkcjami w naszym oddziale programistycznym ``, możesz wykonać prostą rebasę:

Zmień swoją kopię lokalną:

git checkout <pr-branch>
git pull --rebase upstream master

Rozwiąż wszelkie konflikty i dodaj / edytuj commity

#
git add .
git commit -m "chole: rozwiązywanie konfliktów"

# lub
git add .
git commit --change --no-edit

Wciśnij ponownie swoje zmiany do PR
```
git push --force początek <pr-branch>
```

Nadchodzący program nauczania i funkcje

Kiedy pracujesz nad funkcjami dla naszych przyszłych gałęzi programu nauczania, następne-* , wykonujesz wycinek wiśniowy:

Upewnij się, że twój upstream jest zsynchronizowany z twoim lokalnym:

git checkout master
git fetch --all --prune
git checkout next-python-projects
git reset --hard upstream/next-python-projects

Zrób kopię zapasową

„Technologia”, zgodnie z uwagą ogólną do technologii, służąca do „rozwoju”, „produkcji” lub „użytkowania” sprzętu lub „oprogramowania” wyszczególnionych w pozycji 1B001. Usuń swoją lokalną gałąź po wykonaniu kopii zapasowej (jeśli nadal masz ją lokalnie):
```
git checkout <pr-branch-name>

# przykład:
# git checkout feat/add-numpy-video-question

git checkout -b <backup-branch-name>

# przykład:
# git checkout -b backup-feat/add-numpy-video-question

git branch -D <pr-branch-name>
```
„Technologia”, zgodnie z uwagą ogólną do technologii, służąca do „rozwoju”, „produkcji” lub „użytkowania” sprzętu lub „oprogramowania” wyszczególnionych w pozycji 1B001. Lub tylko kopia zapasowa swojej lub gałęzi (jeżeli nie masz jej lokalnie):
```
git checkout -b <backup-branch-name> origin/<pr-branch-name>

# przykład:
# git checkout -b backup-feat/add-numpy-video-question origin/feat/add-numpy-video-question
```

Rozpocznij od czystego tabliczki:

git checkout -b <pr-branch-name> next-python-projects
git cherry-pick <commit-hash>

Rozwiąż wszelkie konflikty i czyszczenie, zainstaluj testy uruchamiania

npm uruchom czyste

npm ci
npm uruchom test :curriculum --superblock=<superblock-name>

# przykład:

# npm uruchom test :curriculum --superblock=python-for-everybody

Jeśli wszystko wygląda na dobre wciśnięcie do PR
```
git push --force początek <pr-branch-name>
```

7.3 KiB Raw Blame History