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 Pliki zmienione: porównanie zmienionych plików w żądaniu ściągnięcia 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 pozycji Utwórz żądanie ściągnięcia usługa GitHub uruchamia walidacje skonfigurowane 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:
- Możliwość scalania: test możliwości scalania w usłudze GitHub punktu odniesienia najpierw sprawdza, 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ółtworzesz repozytorium publiczne i nie jesteś pracownikiem firmy Microsoft, w zależności od wielkości proponowanych zmian, możesz poprosić o ukończenie krótkiego cla przy pierwszym przesłaniu żądania ściągnięcia do tego repozytorium. Po wyczyszczonej operacji CLA twoje żądanie ściągnięcia zostanie przetworzone.
- Etykietowanie: etykiety są automatycznie stosowane do żądania ściągnięcia, aby wskazać jego stan podczas przechodzenia przez przepływ 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. - Weryfikacja i kompilacja: zautomatyzowane kontrole sprawdzają, czy zmiany przeszły 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.
- Przygotowywanie: strony artykułów, których dotyczą zmiany, mogą zostać automatycznie wdrożone w środowisku przygotowawczym na potrzeby przeglądu po pomyślnej weryfikacji i kompilacji. Adresy URL podglądu są udostępniane w komentarzu do żądania ściągnięcia.
- Automatyczne scalanie: Żądanie ściągnięcia może zostać automatycznie scalone, jeśli przejdzie testy poprawności i 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:
Komentarz hasztagu | Co to robi |
---|---|
#sign-off |
Automatycznie przypisuje etykietę ready-to-merge , aby poinformować recenzentów w repozytorium, że żądanie ściągnięcia jest gotowe do przeglądu/scalania. Jeśli nie jesteś autorem na liście i spróbuj zalogować się do publicznego repozytorium żądania ściągnięcia przy użyciu #sign-off komentarza, żądanie ściągnięcia zostanie zaktualizowane, aby wskazać, że tylko autor może przypisać etykietę. |
#hold-off |
Usuwa etykietę w ready-to-merge przypadku zmiany zdania lub popełnienia błędu. |
#please-close |
Zamyka żądanie ściągnięcia, jeśli nie chcesz scalić zmian. |
#please-open |
Otwiera zamknięte żądanie ściągnięcia lub problem. |
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.