Informacje o żądaniach ściągnięcia

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Żądania ściągnięcia to sposób zmiany, przeglądania i scalania kodu w repozytorium Git w usłudze Azure Repos. Żądania ściągnięcia mogą pochodzić z gałęzi w tym samym repozytorium lub z gałęzi w rozwidleniu repozytorium. Zespoły używają pull requestów do przeglądania kodu i przekazywania opinii na temat zmian przed scaleniem kodu z gałęzią główną. Recenzenci mogą przechodzić przez proponowane zmiany, pozostawiać komentarze i głosować, aby zatwierdzić lub odrzucić kod.

W tym artykule opisano wytyczne dotyczące pull requestów i kwestie związane z zarządzaniem. Aby uzyskać instrukcje dotyczące tworzenia, wyświetlania, przeglądania i wykonywania żądań ściągnięcia, zobacz następujące artykuły:

• Tworzenie pull requestów
• Wyświetl i otwórz pull requesty
• Przeglądanie pull requestów
• Wykonywanie żądań ściągnięcia

Uprawnienia i wymagania wstępne

Aby uzyskać więcej informacji o uprawnieniach i dostępie, zobacz Domyślne repozytorium Git i uprawnienia gałęzi oraz Informacje o poziomach dostępu.

Opinie dotyczące jakości pull requestów

Recenzje wysokiej jakości zaczynają się od wysokiej jakości opinii. Oto kilka wskazówek do skutecznego feedbacku dotyczącego PR:

• Właściciel pull requesta powinien zadbać o to, aby odpowiednie osoby dokonały przeglądu i upewnił się, że recenzenci wiedzą, co robi kod.
• Recenzenci powinni udzielić konstruktywnej, możliwej do wdrożenia opinii.
• Właściciele i recenzenci powinni szybko komentować i odpowiadać.

Właściciele pull requestów powinni:

• Pamiętaj, aby wybrać odpowiednich recenzentów do przypisania do PR.
• Uwzględnij recenzentów, którzy wiedzą, jak działa kod.
• Poproś deweloperów pracujących w innych obszarach, aby podzielili się swoimi pomysłami.
• Podaj jasny opis zmian.
• Udostępnij recenzentom wskazówki przy użyciu szablonów próśb o dołączenie.
• Podaj kompilację kodu z uruchomioną poprawką lub funkcją.
• Odpowiedz na komentarze, akceptując sugestię lub wyjaśniając, dlaczego sugerowana zmiana nie jest idealna.
• Dla dobrych sugestii poza zakresem PR, utwórz nowe elementy robocze, gałęzie i pull requesty, aby wprowadzić te zmiany.

Recenzenci powinni wykonywać następujące zadania.

• Prześlij opinię na temat zmian, z którymi nie zgadzają się
• Identyfikowanie problemów i nadawanie konkretnych sugestii dotyczących tego, co należy zrobić inaczej
• Upewnij się, że opinia ma wyraźną intencję i jest łatwa do zrozumienia
• Pozostawianie komentarzy lub głosowanie nad zmianami

Aby uzyskać więcej informacji, zobacz Uzyskiwanie opinii za pomocą żądań ściągnięcia w Git.

Polityki gałęzi i pull requesty

Twój zespół może polegać na gałęziach krytycznych w repozytorium, takich jak main gałąź, aby zawsze mieć dobrą formę. Można ustawić polityki gałęzi, aby wymagać żądań ściągnięcia dla każdej zmiany w tych chronionych gałęziach i odrzucić wszelkie zmiany przesłane bezpośrednio do gałęzi.

Możesz dodać więcej polityk do Pull Requestów, aby wymusić lepszą jakość kodu w kluczowych gałęziach. Dodatkowe wymagania, takie jak czysta kompilacja proponowanego kodu lub zatwierdzenia przez wielu recenzentów, mogą pomóc w ochronie kluczowych gałęzi.

Liczbę wymaganych zatwierdzeń dla pull requesta można ustawić w zasadach gałęzi. Można również ustawić, że niektórzy recenzenci mają być wymagane lub opcjonalne dla wszystkich lub niektórych żądania ściągnięcia. Żądanie ściągnięcia (pull request) można ustawić na automatyczne uzupełnianie z wymaganą liczbą zatwierdzeń, nawet jeśli inni recenzenci odrzucą zmiany. Jednak wymagani recenzenci muszą zatwierdzić PR-y, zanim PR-y będą mogły zostać scalone. Zaleca się, aby zmiany w znaczącym pull request były przeglądane i zatwierdzane przez co najmniej dwóch recenzentów.

Aby zresetować głosy za każdym razem, gdy autor żądania ściągnięcia wprowadza nowe zmiany, wybierz pozycję Resetuj głosy recenzentów, gdy są nowe zmiany w polityce gałęzi Wymagaj minimalnej liczby recenzentów.

Poniższa tabela zawiera podsumowanie zasad, które można zdefiniować w celu dostosowania gałęzi. Aby zapoznać się z omówieniem wszystkich zasad i ustawień repozytorium oraz gałęzi, zobacz Ustawienia i zasady repozytorium Git.

Aby uzyskać więcej informacji, zobacz:

• Omówienie polityk oddziałów
• Jak skonfigurować zasady dotyczące gałęzi
• Uprawnienia gałęzi
• Tworzenie niestandardowych zasad rozgałęziania za pomocą usługi Azure Functions

Definiowanie kontroli stanu w celu poprawy jakości kodu

Żądania wciągnięcia i zasady gałęzi umożliwiają zespołom egzekwowanie najlepszych praktyk dotyczących przeglądania kodu i uruchamiania automatycznych kompilacji. Wiele zespołów ma dodatkowe wymagania i walidacje, które należy wykonać w kodzie. Aby uwzględnić te potrzeby, możesz zintegrować kontrole stanu PR z przepływem pracy PR. W przypadku sprawdzania statusu pull request, usługi zewnętrzne mogą programowo zatwierdzać zmiany w kodzie, kojarząc informacje o powodzeniu lub niepowodzeniu z pull request.

Aby uzyskać więcej informacji, zobacz następujące artykuły:

• Dostosowywanie i rozszerzanie przepływów pracy dla pull requestów przy użyciu ich statusu
• Tworzenie serwera statusu PR przy użyciu Node.js
• Konfigurowanie zasad rozgałęziania dla usługi zewnętrznej

Problem z wieloma bazami scalania

W niektórych przypadkach PR ma więcej niż jeden prawdziwy punkt początkowy scalania, a taka sytuacja może prowadzić do problemów z bezpieczeństwem. Jeśli pliki w pull request mają różne wersje w różnych bazach scalania, pojawia się ostrzeżenie o wielu bazach scalania. Aby uzyskać więcej informacji i korekty, zobacz Wiele baz scalania.

Następne kroki

• Zwiększanie jakości kodu za pomocą zasad gałęzi
• Dostosowywanie i rozszerzanie przepływów pracy dla pull requestów przy użyciu ich statusu
• Powiadomienia o aktualizacji pull request
• Zmienianie gałęzi domyślnej
• Kopiowanie zmian za pomocą funkcji cherry-pick
• Strategie scalania i scalanie z redukcją
• Wiele baz scalania