Przejdź do głównej zawartości

Zrecenzuj i scal PR

Ten poradnik pokazuje, jak zrecenzować i scalić pull request.

  1. W pasku bocznym przejdź do Pull requesty
  2. Wybierz PR z listy

PR otwiera się jako warsztat z kartami, a nie pojedyncza strona. Domyślnie otwiera się pięć kart, w tej kolejności: Przegląd, Diff, Kontrola wersji, Czat i Akcje (kontrole CI pogrupowane według workflow). Recenzja — postęp potoku recenzji, a następnie opublikowany przez niego artefakt wraz z panelem ustaleń — celowo nie należy do nich: PR nie ma recenzji, dopóki ktoś o nią nie poprosi, więc otwiera ją Zapytaj AI. Terminal, edytor jednego pliku, osadzony code-server i przeglądarka w aplikacji otwierają się na żądanie; karty podglądu wdrożenia są wstrzykiwane automatycznie, gdy na PR zostanie wykryty adres URL podglądu. Układ kart jest zapamiętywany dla każdego PR-a.

Karta Przegląd niesie metadane PR-a (autor, gałąź, etykiety, przypisane osoby, reakcje, commity, stan kontroli) oraz wiersz akcji: odśwież, Recenzja, Scal, otwórz w IDE i menu przepełnienia ⋯.

Otwórz kartę Diff, aby zobaczyć cały diff PR-a naraz, z drzewem plików do przeskakiwania między nimi.

  • Przycisk ustawień na pasku narzędzi diffu przełącza widok podzielony (obok siebie) i ujednolicony oraz włącza lub wyłącza zawijanie wierszy i ligatury czcionki kodu.
  • Nagłówki fragmentów @@ są zastępowane elementami Show N lines / Show end of file, które po kliknięciu wstawiają otaczający kontekst.
  • Naciśnij j / k, aby przechodzić między plikami, c, aby zwinąć lub rozwinąć aktywny plik, t, aby przywrócić w pasku bocznym drzewo plików, a ⌘F, aby przeszukać cały diff (Enter / Shift+Enter przechodzą przez trafienia).
  • Naciśnij v, aby oznaczyć aktywny plik jako wyświetlony; kursor przechodzi wtedy do następnego pliku. W GitHubie stan wyświetlenia jest przechowywany na forge, więc podąża za Tobą między klientami; GitLab i Bitbucket nie mają takiego API, więc tam jest pamiętany tylko na tym urządzeniu.

Przeciągnięcie myszą w obszarze kodu zaznacza tekst do dokładnej kolumny, a ⌘C kopiuje surowe źródło, a nie renderowane znaczniki diffu.

  1. Kliknij margines wiersza kodu, aby otworzyć edytor komentarza zakotwiczony w tym wierszu, albo użyj przycisku + w nagłówku pliku, aby dodać komentarz na poziomie pliku
  2. Napisz swoją opinię w Markdownie
  3. Wyślij

W GitHubie i GitLabie edytor oferuje dwa sposoby wysłania: Dodaj pojedynczy komentarz publikuje od razu, a Rozpocznij recenzję / Dodaj do recenzji umieszcza komentarz w oczekującej recenzji, która wychodzi wraz z Zatwierdź, Zażądaj zmian lub Komentarz. Bitbucket nie grupuje oczekujących recenzji, więc tam każde wysłanie publikuje od razu. Natychmiastowa publikacja pokazuje stan oczekiwania, dopóki forge go nie potwierdzi, a potem przechodzi w stan zsynchronizowany. Jeśli publikacja się nie powiedzie, wątek zostaje oznaczony błędem i proponuje ponowną próbę.

Tylko treść recenzji jest wersją roboczą: jest zapisywana po stronie serwera dla trójki (właściciel, repozytorium, numer PR) chwilę po tym, jak przestaniesz pisać, dzięki czemu przetrwa przeładowanie i podąża za Tobą między klientem desktopowym a webowym.

  1. Naciśnij Recenzja w wierszu akcji na karcie Przegląd (jest ukryty przy Twoich własnych PR-ach oraz przy PR-ze zamkniętym lub scalonym)
  2. Napisz treść recenzji. Możesz załączyć obraz, wstawić emoji lub GIF i przełączać się między pisaniem a podglądem
  3. Naciśnij Zażądaj zmian, Komentarz lub Zatwierdź

Werdykt jest przyciskiem — nie ma osobnego selektora werdyktu. Po Zatwierdź lub Zażądaj zmian przycisk zmienia etykietę na Zatwierdzono lub Zażądane zmiany, a treść wersji roboczej zostaje wyczyszczona. Werdykt Komentarz pozostawia przycisk z etykietą Recenzja.

Przycisk Scal pojawia się, gdy masz uprawnienia do zapisu, a PR jest otwarty i nie jest wersją roboczą. Jego kolor to sygnał gotowości wyliczony z wymaganych zatwierdzeń i stanu kontroli (gotowy / oczekujący / zablokowany) — ma wyłącznie charakter informacyjny. Stan recenzji nigdy nie wyłącza tego przycisku; reguły egzekwuje ochrona gałęzi po stronie forge.

  1. Naciśnij Scal, aby otworzyć panel scalania
  2. Wybierz metodę scalania: squash, commit scalający lub rebase (domyślnie squash). Bitbucket nie ma prawdziwego scalania przez rebase, więc rebase jest mapowany na jego strategię fast-forward i kończy się niepowodzeniem na rozjeżdżonej gałęzi
  3. W przypadku squash i commita scalającego edytuj wstępnie wypełniony tytuł i opis commita. Rebase nie przyjmuje żadnego z nich i ukrywa oba pola
  4. Przeczytaj panel ostrzeżeń — wymienia nieudane kontrole i oczekujące recenzje, ale Cię nie blokuje
  5. Naciśnij przycisk scalania w panelu, aby potwierdzić

Scalanie jest nieodwracalne: wypycha commity na forge, więc zamiast wpisu cofania dostaje krok potwierdzenia. Następnie pamięć podręczna PR-a jest unieważniana, jego status zmienia się na Scalono, a zdarzenie PullRequestStatusChanged zostaje wywołane ze statusem merged. To zdarzenie zwalnia efemeryczny worktree „otwórz w edytorze” i uruchamia dwa wbudowane potoki: Stale repository cleanup, który usuwa nieaktualne worktree i foldery rozmów PR-a, oraz Release notes, który tworzy projekt wpisu w changelogu.

Menu przepełnienia ⋯ na karcie Przegląd zawiera Zapytaj AI, które uruchamia wbudowany potok pr_review dla tego PR-a. Pojawia się tylko wtedy, gdy PR jest otwarty. Zobacz Używaj recenzji opartej na AI, aby dowiedzieć się, co robi potok i jak opublikować jego ustalenia, oraz Obliczenia recenzji o deterministycznym modelu kohort i osi.

Control Center importuje także PR-y otwarte przez ludzi poza aplikacją. Powyższy przebieg recenzji jest identyczny. Zewnętrzne PR-y są wykrywane przez usługę odpytywania PR-ów.