Przeglądanie i przesyłanie żądania ściągnięcia

Żądanie ściągnięcia to twój bilet na uzyskanie wiedzy na platformie Learn. Utworzono żądanie ściągnięcia, ale nie zostało jeszcze przesłane do kolejki żądania ściągnięcia repozytorium docelowego. Podobnie jak w przypadku wielu projektów typu open source, istnieje seria kontroli i przeglądów, które mają miejsce w celu zweryfikowania zmian przed opublikowaniem.

Anatomia żądania ściągnięcia

Żądanie ściągnięcia przedstawia użytkownika usługi GitHub, który utworzył żądanie ściągnięcia, repozytorium docelowe i gałąź, w której utworzono żądanie ściągnięcia. Żądania ściągnięcia zawierają kilka kart u góry, w tym:

• Karta Konwersacja: pulpit nawigacyjny, na którym można wyświetlać komentarze innych współpracowników i odpowiadać na nie, wyświetlać listę powiadomień w całym procesie kompilacji i przeglądu oraz używać automatyzacji komentarzy do wykonywania akcji.
• Karta Zatwierdzenia: Rekord zmian wprowadzonych w tej gałęzi.
• Karta zmienionych plików: porównanie zmienionych plików w pull request z ich poprzednim stanem.

Zwróć szczególną uwagę na kartę Konwersacja, w której są wyświetlane wszelkie aktualizacje lub powiadomienia, a także wszelkie dyskusje między Tobą, recenzentami i innymi współpracownikami. Możesz również dodać tutaj komentarze hasztagu, aby wykonać akcje, takie jak wylogowanie się z żądania ściągnięcia, aby wskazać, że jest gotowe do zweryfikowania i scalenia lub wstrzymanie, jeśli trzeba wstrzymać proces.

Żądania ściągnięcia często mają dołączone etykiety, aby wskazać ich stan, na draft przykład w celu określenia wersji roboczej żądania ściągnięcia, które nie są gotowe do przeglądu, lub do-not-merge żądania ściągnięcia, które są nowe lub nieoglądane.

Walidacja

Zanim żądanie ściągnięcia zostanie scalone z gałęzią docelową, może być wymagane przejście przez co najmniej jeden proces weryfikacji żądania ściągnięcia. Po wybraniu opcji Utwórz prośbę o ściągnięcie, GitHub uruchamia zaplanowane walidacje dla repozytorium. Po zakończeniu procesu weryfikacji wyniki są wyświetlane w żądaniu ściągnięcia.

Procesy weryfikacji różnią się w zależności od zakresu proponowanych zmian i reguł repozytorium docelowego. Po przesłaniu żądania ściągnięcia można oczekiwać, że nastąpi co najmniej jedna z następujących czynności:

• Scalanie: bazowy test scalania GitHub najpierw weryfikuje, czy proponowane zmiany w gałęzi są w konflikcie z gałęzią docelową. Jeśli żądanie ściągnięcia wskazuje, że ten test zakończył się niepowodzeniem, musisz uzgodnić zawartość powodującą konflikt scalania, zanim będzie można kontynuować przetwarzanie.
• Umowa licencjonowania współtworzenia (CLA): Jeśli współtworzysz repozytorium publiczne i nie jesteś pracownikiem firmy Microsoft, w zależności od wielkości proponowanych zmian, możesz zostać poproszony o ukończenie krótkiej CLA przy pierwszym przesłaniu PR do tego repozytorium. Po wyczyszczonej operacji CLA twoje żądanie ściągnięcia zostanie przetworzone.
• Etykietowanie: etykiety są automatycznie stosowane do pull requestów, aby wskazać ich status podczas przechodzenia przez proces przepływu pracy weryfikacji. Na przykład nowe żądania ściągnięcia mogą automatycznie odbierać etykietę, co oznacza, że żądanie ściągnięcia do-not-merge nie zakończyło jeszcze czynności weryfikacji, przeglądu i wylogowania.
• Walidacja i kompilacja: Automatyczne sprawdzanie sprawdza, czy zmiany przechodzą testy weryfikacyjne. Testy weryfikacyjne mogą zwracać ostrzeżenia lub błędy, co wymaga wprowadzenia zmian w co najmniej jednym pliku w żądaniu ściągnięcia, zanim będzie można je scalić. Wyniki testu weryfikacji są dodawane jako komentarz w żądaniu ściągnięcia do przeglądu i mogą być również wysyłane do Ciebie w wiadomości e-mail.
• Środowisko testowe: strony artykułów zmienionych przez ciebie są automatycznie wdrażane w środowisku testowym do przeglądu po pomyślnej walidacji i kompilacji. Adresy URL podglądu są udostępniane w komentarzu do żądania ściągnięcia.
• Automatyczne scalanie: PR może zostać automatycznie scalone, jeśli przejdzie walidacyjne testy i spełni określone kryteria. W takim przypadku nie musisz wykonywać żadnych innych czynności.

Przejrzyj i wyloguj się

Prawie gotowe. Po zakończeniu przetwarzania wszystkich żądań ściągnięcia najlepszym rozwiązaniem jest przejrzenie wyników (na przykład komentarzy do żądania ściągnięcia, adresów URL podglądu) w celu określenia, czy przed rozpoczęciem scalania jest wymagana większa liczba zmian. Jeśli recenzent żądania ściągnięcia przejrzył żądanie ściągnięcia, może również przekazać opinię za pośrednictwem komentarzy, jeśli występują problemy lub pytania uniemożliwiające scalanie.

Automatyzacja komentarzy umożliwia wykonywanie ważnych akcji w żądaniu ściągnięcia. Automatyzacja komentarzy umożliwia użytkownikom przypisanie odpowiedniej etykiety do żądania ściągnięcia w celu zaktualizowania stanu lub kategoryzowania. Jeśli pracujesz w repozytorium, w którym zaimplementowano automatyzację komentarzy, użyj komentarzy hashtagu, aby przypisać lub zmienić etykiety, zamknąć żądanie ściągnięcia lub wstrzymać scalanie. Na przykład po zakończeniu wprowadzania zmian wpisz komentarz #sign-off , aby zmienić etykietę żądania ściągnięcia z do-not-merge na ready-for-review.

Użyj komentarzy w poniższej tabeli, aby wykonać kluczowe akcje w żądaniu ściągnięcia:

Aby scalić zmiany, musisz wprowadzić #sign-off komentarz. Nawet jeśli wszystkie przeglądy i testy weryfikacji są przekazywane, odpowiadasz za użycie tego komentarza, aby poinformować recenzentów żądania ściągnięcia i administratorów repozytorium, że zmiany są gotowe do scalenia ze strony rzeczy. Gdy recenzenci zdecydują, że żądanie ściągnięcia jest wolne od problemów i jest podpisane, zmiany są scalane z powrotem do gałęzi nadrzędnej, a żądanie ściągnięcia jest zamknięte.

Publikowanie

Należy pamiętać, że żądanie ściągnięcia musi zostać scalone przez recenzenta żądania ściągnięcia, zanim zmiany zostaną uwzględnione w następnym zaplanowanym przebiegu publikowania. Zwykle żądania ściągnięcia są przeglądane i scalane w kolejności przesyłania.

Po zatwierdzeniu i scaleniu kontrybucyjnie proces publikowania je pobiera. W zależności od zespołu, który zarządza repozytorium, do którego współtworzysz, czasy publikowania mogą się różnić, ale zazwyczaj występują co najmniej raz w każdym dniu tygodnia. Artykuły mogą zostać wyświetlone online do 45 minut po opublikowaniu.

Po opublikowaniu zmian będą one na żywo w witrynie Microsoft Learn dla innych użytkowników, od których będą się uczyć!

Scenariusz: Publikowanie zmian w usłudze aplikacja systemu Azure

W przeszłości zauważono możliwość dodania przydatnych informacji do strony dokumentacji usługi App Service i utworzenia żądania ściągnięcia w celu dodania zmian. Teraz możesz przejrzeć żądanie ściągnięcia i wylogować się, aby opublikować zmiany.