Frontend Academy · Lekcja

Praca z pull requestami na GitHubie

Proszę otworzyć pull request na GitHubie, napisać pomocny opis, odpowiadać na komentarze w code review oraz scalać zmiany po uzyskaniu akceptacji.

Praca z pull requestami na GitHubie to bezpłatna lekcja Frontend Academy na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Frontend Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Frontend Academy zawiera 4 lekcji w sumie.

Czym jest Pull Request?

Pull Request (PR) to propozycja scalenia jednej gałęzi z inną. W GitHub tworzy on wątek dyskusji, w którym osoby z zespołu sprawdzają kod, dodają komentarze, proszą o zmiany, a ostatecznie zatwierdzają scalenie.

Tworzenie PR w GitHub

Po wysłaniu gałęzi funkcjonalności do GitHub pojawia się żółty baner z propozycją porównania gałęzi i utworzenia PR. Kliknij go albo przejdź do Pull Requests → New pull request i wybierz swoje gałęzie.

Pisanie dobrego opisu PR

Dobry opis PR wyjaśnia, co się zmieniło i dlaczego. W przypadku zmian w interfejsie użytkownika dołącz zrzut ekranu. Dodaj odnośnik do powiązanego zadania. Opisz sposób przetestowania zmian. Czytelnik nie powinien musieć czytać kodu, aby zrozumieć intencję zmian.

## Summary
Adds dark mode support using CSS custom properties.

## Why
Users requested dark mode (#123). Reduces eye strain for evening use.

## Testing
- Toggled dark/light mode on macOS and Windows
- Verified `prefers-color-scheme: dark` auto-triggers
- Tested with a screen reader (macOS VoiceOver)

Proszenie o sprawdzenie kodu

Przypisz konkretne osoby z zespołu jako sprawdzających. Otrzymają powiadomienie i będą mogły zatwierdzić zmiany, poprosić o ich wprowadzenie albo dodać komentarz. Większość zespołów wymaga co najmniej jednego zatwierdzenia przed scaleniem.

Czytanie komentarzy do przeglądu kodu

Komentarze pojawiają się bezpośrednio przy zmienionych wierszach. Osoby sprawdzające mogą poprosić o wyjaśnienia, zasugerować inne podejście albo zatwierdzić zmiany. Odpowiadaj na każdy komentarz — wprowadzając zmianę w kodzie albo wyjaśniając, dlaczego nie została wprowadzona.

Reagowanie na żądane zmiany

Gdy osoba sprawdzająca poprosi o zmiany, wysyłaj nowe commity do tej samej gałęzi. PR zaktualizuje się automatycznie. Po uwzględnieniu uwagi zakończ każdą rozmowę, klikając „Resolve conversation”.

Robocze PR

Otwórz PR jako Draft, aby zasygnalizować, że praca jest w toku. Robocze PR nadal umożliwiają sprawdzanie kodu i dyskusję, ale nie można ich przypadkowo scalić. Po ukończeniu zmień status na Ready.

Aktualizowanie gałęzi

Gdy podczas sprawdzania kodu gałąź main posunie się naprzód, wykonaj rebase swojej gałęzi na podstawie najnowszej wersji main, aby uniknąć konfliktów i upewnić się, że zmiany działają z nowym kodem.

git fetch origin
git rebase origin/main
git push --force-with-lease origin feature/dark-mode

Squash merge a commit scalający i rebase

GitHub oferuje trzy strategie scalania: Merge commit (zachowuje wszystkie commity), Squash and merge (jeden commit na PR, czysta historia main) oraz Rebase and merge (historia liniowa, bez commita scalającego). Zespoły zazwyczaj wybierają jedną strategię, aby zachować spójność.

Reguły ochrony gałęzi

Chroń main, wymagając sprawdzenia PR, pomyślnego przejścia kontroli statusu (CI) oraz zakazując bezpośredniego wysyłania zmian. Ustawienia znajdują się w GitHub → Settings → Branches.

Zasady dobrego PR

PR-y powinny być małe i skoncentrowane na jednym celu. Jeden PR powinien dotyczyć jednej funkcji albo poprawki. Duże PR-y trudno sprawdzać. Odpowiadaj na komentarze z przeglądu w ciągu jednego dnia. Dziękuj osobom sprawdzającym. Zachowuj życzliwość — przegląd kodu jest okazją do nauki, a nie audytem.

Szybkie sprawdzenie

Co powinien zawierać dobry opis PR?

Podsumowanie: przepływ pracy z Pull Requestami

Wyślij gałąź funkcjonalności → otwórz PR z jasnym opisem → poproś o sprawdzenie kodu → uwzględnij uwagi za pomocą nowych commitów → aktualizuj gałąź przez rebase → uzyskaj zatwierdzenie → scal zmiany. PR-y powinny być małe, skoncentrowane na jednym celu i dobrze opisane. Reguły ochrony gałęzi pomagają egzekwować jakość na main.

Często zadawane pytania

Czy lekcja „Praca z pull requestami na GitHubie” jest bezpłatna?

Tak — pełny tekst „Praca z pull requestami na GitHubie” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Frontend Academy, przejdź na CoddyKit PRO. Kurs Frontend Academy zawiera 4 lekcji w sumie.

Co nauczysz się w „Praca z pull requestami na GitHubie”?

Proszę otworzyć pull request na GitHubie, napisać pomocny opis, odpowiadać na komentarze w code review oraz scalać zmiany po uzyskaniu akceptacji. Ćwiczysz Frontend Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Frontend Academy?

Nie wymagamy żadnego doświadczenia. Frontend Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.

Ile czasu zajmuje lekcja „Praca z pull requestami na GitHubie”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Frontend Academy?

Tak. Każda lekcja Frontend Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

← Powrót do Frontend Academy