Zarządzanie Pull Requestami

Nieoficjalne Tłumaczenie Beta

Ta strona została przetłumaczona przez PageTurner AI (beta). Nie jest oficjalnie zatwierdzona przez projekt. Znalazłeś błąd? Zgłoś problem →

Przeglądanie pull requesta może zająć znacznie czasu. W niektórych przypadkach przegląd może trwać dłużej niż samo przygotowanie i przesłanie zmian! Dlatego konieczne jest przeprowadzenie wstępnych działań, aby upewnić się, że każdy pull request jest gotowy do recenzji.

Pull request powinien składać się z trzech głównych sekcji:

• Podsumowanie. Pomaga nam zrozumieć motywację stojącą za zmianami.

• Dziennik zmian (changelog). Pomaga nam w tworzeniu informacji o wydaniu. Stanowi też krótkie podsumowanie wprowadzonych zmian.

• Plan testów. To prawdopodobnie najważniejsza część pull requesta. Plan testów powinien być powtarzalnym przewodnikiem krok po kroku, aby recenzent mógł zweryfikować działanie zmian. Dla zmian widocznych dla użytkownika warto dodać zrzuty ekranu lub nagrania.

Każdy pull request może wymagać głębszego zrozumienia obszaru React Native, z którym możesz nie być zaznajomiony. Nawet jeśli nie czujesz się odpowiednią osobą do recenzji, możesz pomóc poprzez dodanie etykiet lub poproszenie autora o dodatkowe informacje.

Przeglądanie PR-ów

Pull Requesty muszą zostać przejrzane i zatwierdzone za pomocą funkcji recenzji GitHub, zanim będzie możliwe ich scalenie. Choć każdy może dokonać recenzji i zatwierdzenia pull requesta, zazwyczaj uznajemy go za gotowego do scalenia dopiero po zatwierdzeniu przez jednego z współtwórców.

Jeśli znalazłeś pull request, który czujesz się pewnie recenzować, skorzystaj z funkcji recenzji GitHub i jasno oraz uprzejmie przekazuj wszystkie sugerowane zmiany.

Rozważ rozpoczęcie od pull requestów oznaczonych jako brakujące dziennika zmian lub planu testów.

• PR-y bez dziennika zmian - sprawdź, czy możesz samodzielnie dodać changelog poprzez edycję PR. Następnie usuń etykietę "Missing Changelog".

• PR-y bez planu testów - otwórz pull request i poszukaj planu testów. Jeśli plan wydaje się wystarczający, usuń etykietę "Missing Test Plan". Jeśli planu brakuje lub jest niekompletny, dodaj komentarz z uprzejmą prośbą do autora o jego uzupełnienie.

Pull request musi przejść wszystkie testy przed scaleniem. Testy są uruchamiane przy każdym commicie na gałęzi main i w pull requeście. Szybkim sposobem na przygotowanie PR-ów do recenzji jest wyszukanie pull requestów z błędami w testach przed-commitowych i ustalenie, czy wymagają poprawek. Informacja o niezdanym teście zwykle znajduje się na dole wątku, pod sekcją "Some checks were not successful".

• Sprawdź ostatnie przebiegi testów na main. Czy main jest "zielony"? Jeśli tak:

  • Czy błąd może być związany ze zmianami w tym pull requeście? Poproś autora o zbadanie.
  • Nawet jeśli main jest aktualnie "zielony", rozważ możliwość, że commity w pull requeście mogą być oparte na wersji, w której main był uszkodzony. Jeśli tak może być, poproś autora o rebazowanie zmian na aktualny main, aby uwzględnić poprawki dodane po rozpoczęciu pracy nad PR.

• Jeśli gałąź main wydaje się być uszkodzona, poszukaj zgłoszeń oznaczonych etykietą "CI Test Failure".

  • Jeśli znajdziesz zgłoszenie związane z błędem w main, wróć do pull requesta i podziękuj autorowi za propozycję zmian, informując, że błąd testów może nie być związany z jego zmianami (nie zapomnij podlinkować zgłoszenia o błędzie CI, co pomoże autorowi śledzić sytuację).
  • Jeśli nie znajdziesz istniejącego zgłoszenia opisującego problem w main, utwórz nowe zgłoszenie z etykietą "CI Test Failure", aby poinformować innych o awarii main (przykład: to zgłoszenie).

Priorytetyzacja pull requestów

Członkowie zespołu React Native w Meta dążą do szybkiego przeglądania pull requestów – większość otrzyma odpowiedź w ciągu tygodnia.

Jak pull request jest scalany?

Repozytorium React Native na GitHubie jest lustrzanym odbiciem podkatalogu z monorepo Meta. Pull requesty nie są więc scalane tradycyjnie. Zamiast tego są importowane do wewnętrznego systemu przeglądu kodu jako "diff".

Po zaimportowaniu zmiany przechodzą zestaw testów. Niektóre testy blokują scalenie (land-blocking). Meta zawsze używa React Native z gałęzi main, a niektóre zmiany wymagają dołączenia przez pracownika Facebooka wewnętrznych poprawek. Np. przy zmianie nazwy modułu, wszystkie wewnętrzne odwołania w Meta muszą zostać zaktualizowane w tej samej zmianie. Jeśli diff zostanie pomyślnie zaaplikowany, zmiany zostaną zsynchronizowane z GitHubem przez ShipIt jako pojedynczy commit.

Pracownicy Meta używają specjalnej wtyczki przeglądarkowej do GitHub, która importuje pull requesta na dwa sposoby: "landed to fbsource" (automatyczna akceptacja po importowaniu, a zmiany ostatecznie zsynchronizują się z main o ile nie wystąpią błędy) lub "imported to Phabricator" (wymagający dodatkowej recenzji wewnętrznej przed scaleniem).

Screenshot of the custom browser extension. The button "Import to fbsource" is used to import a Pull Request internally.

Boty

Podczas pracy z pull requestami możesz napotkać komentarze od botów GitHub. Zostały skonfigurowane, aby wspomóc proces recenzji. Szczegóły w dokumentacji botów.

Etykiety pull requestów

• Merged: Oznacza, że zmiany zostały włączone do głównego repozytorium. Używamy tej etykiety, bo pull requesty nie są scalane bezpośrednio na GitHubie. Zamiast tego zmiany są importowane i recenzowane wewnętrznie, a wynik scalenia synchronizowany jako nowy commit.

• Blocked on FB: Pull request został zaimportowany, ale zmiany nie zostały jeszcze zastosowane.