Udostępnij za pośrednictwem

Zasady i ustawienia gałęzi

  • Artykuł

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Zasady dotyczące gałęzi pomagają zespołom chronić swoje ważne gałęzie rozwoju. Zasady wymuszają jakość kodu zespołu i standardy zarządzania zmianami. W tym artykule opisano sposób ustawiania zasad gałęzi i zarządzania nimi. Aby zapoznać się z omówieniem wszystkich zasad i ustawień repozytorium oraz gałęzi, zobacz Ustawienia i zasady repozytorium Git.

Nie można usunąć gałęzi, w której skonfigurowano wymagane zasady; wymagane są żądania ściągnięcia (pull requesty) dla wszystkich zmian.

Wymagania wstępne

  • Aby ustawić zasady gałęzi, należy być członkiem grupy zabezpieczeń Administratorzy projektu lub mieć uprawnienia na poziomie repozytorium Edytuj zasady. Aby uzyskać więcej informacji, zobacz Ustawianie uprawnień repozytorium Git.

  • Jeśli chcesz używać poleceń az repos policy interfejsu wiersza polecenia usługi Azure DevOps do zarządzania zasadami gałęzi, wykonaj kroki opisane w artykule Rozpocznij pracę z Azure DevOps CLI.

  • Aby ustawić zasady gałęzi, należy być członkiem grupy zabezpieczeń Administratorzy projektu lub mieć uprawnienia na poziomie repozytorium Edytuj zasady. Aby uzyskać więcej informacji, zobacz Ustawianie uprawnień repozytorium Git.

Konfigurowanie zasad gałęzi

Aby zarządzać zasadami gałęzi, wybierz Repozytoria>Gałęzie, aby otworzyć stronę Gałęzie w portalu internetowym.

Zrzut ekranu przedstawiający element menu Gałęzie.

Możesz również przejść do ustawień zasad gałęzi za pomocą Ustawienia projektu>Repozytorium>Zasady>Zasady gałęzi><Nazwa gałęzi>.

Gałęzie, które mają zasady, wyświetlają ikonę zasad. Możesz wybrać ikonę, aby przejść bezpośrednio do ustawień zasad gałęzi.

Aby ustawić zasady gałęzi, znajdź gałąź, którą chcesz zarządzać. Możesz przeglądać listę lub wyszukiwać gałąź w polu Nazwa gałęzi wyszukiwania w prawym górnym rogu.

Wybierz ikonę Więcej opcji obok gałęzi, a następnie wybierz pozycję Zasady gałęzi z menu kontekstowego.

Zrzut ekranu przedstawiający otwieranie zasad gałęzi z menu kontekstowego.

Skonfiguruj zasady na stronie ustawień gałęzi. Zapoznaj się z poniższymi sekcjami, aby uzyskać opisy i instrukcje dotyczące poszczególnych typów zasad.

Wymaganie minimalnej liczby recenzentów

Przeglądy kodu są ważne dla projektów programistycznych. Aby upewnić się, że zespoły dokonują rewizji i zatwierdzają żądania ściągnięcia, możesz wymagać zatwierdzenia od minimalnej liczby recenzentów. Podstawowe zasady wymagają, aby określona liczba recenzentów zatwierdzała kod bez odrzucenia.

Aby ustawić zasady, w obszarze Zasady dla gałęzi ustaw opcję Wymagaj minimalnej liczby recenzentów na Włączone. Wprowadź wymaganą liczbę recenzentów i wybierz dowolną z następujących opcji:

Zrzut ekranu przedstawiający zasady Włącz przeglądy kodu.

  • Wybierz Zezwalaj osobom składającym żądania na zatwierdzenie własnych zmian, aby umożliwić twórcy PR głosowanie nad jego zatwierdzeniem. W przeciwnym razie twórca może nadal głosować Zatwierdź w PR, ale ich głos nie jest wliczany do minimalnej liczby recenzentów.

  • Wybierz opcję Zakazać najnowszemu autorowi zatwierdzania własnych zmian , aby wymusić segregację obowiązków. Domyślnie każda osoba z uprawnieniami do zapisu w gałęzi źródłowej może zarówno dodawać commity, jak i głosować za zatwierdzeniem żądania ściągnięcia. Wybranie tej opcji oznacza, że ostatni głos wypychacza nie jest liczony, nawet jeśli on sam zwykle może zatwierdzić własne zmiany.

  • Wybierz Zezwalaj na ukończenie nawet jeśli niektórzy recenzenci głosują, aby poczekać lub odrzucić, aby umożliwić ukończenie PR, nawet jeśli niektórzy recenzenci są przeciwni zatwierdzeniu. Minimalna liczba recenzentów musi nadal zatwierdzać.

  • W obszarze Po wypchnięciu nowych zmian:
    • Wybierz pozycję Wymagaj co najmniej jednego zatwierdzenia w ostatniej iteracji , aby wymagać co najmniej jednego głosowania za zatwierdzeniem ostatniej zmiany gałęzi źródłowej.
    • Wybierz pozycję Resetuj wszystkie głosy zatwierdzenia (nie resetuje głosów do odrzucenia lub oczekiwania), aby usunąć wszystkie głosy zatwierdzenia, ale zachowaj głosy do odrzucenia lub oczekiwania, zawsze gdy zmienia się gałąź źródłowa.
    • Wybierz pozycję Resetuj wszystkie głosy recenzenta kodu, aby usunąć wszystkie głosy recenzentów za każdym razem, gdy gałąź źródłowa ulegnie zmianie, w tym głosy zatwierdzające, odrzucające lub oczekujące.
  • W obszarze Kiedy nowe zmiany są wypychane:
    • Wybierz pozycję Wymagaj co najmniej jednego zatwierdzenia dla każdej iteracji , aby wymagać co najmniej jednego głosowania za zatwierdzeniem ostatniej zmiany gałęzi źródłowej. Zgoda użytkownika nie jest uwzględniana wobec żadnej wcześniejszej niezatwierdzonej iteracji dokonanej przez tego użytkownika. W związku z tym inne zatwierdzenie ostatniej iteracji jest wymagane przez innego użytkownika. Wymagaj co najmniej jednego zatwierdzenia dla każdej iteracji jest dostępne w Azure DevOps Server 2022.1 i nowszych.
    • Wybierz Wymagaj co najmniej jednego zatwierdzenia w ostatniej iteracji, aby wymagać co najmniej jednego głosowania za zatwierdzeniem przy ostatniej zmianie gałęzi źródłowej.
    • Wybierz pozycję Resetuj wszystkie głosy zatwierdzenia (nie resetuje głosów do odrzucenia lub oczekiwania), aby usunąć wszystkie głosy zatwierdzenia, ale zachowaj głosy do odrzucenia lub oczekiwania, zawsze gdy zmienia się gałąź źródłowa.
    • Wybierz Resetuj wszystkie głosy recenzentów kodu, aby usunąć wszystkie głosy recenzentów, w tym głosy zatwierdzające, odrzucające lub wstrzymujące, za każdym razem, gdy zmieni się gałąź źródłowa.

Jeśli wszystkie inne zasady zostaną spełnione, twórca może ukończyć pull request, gdy wymagana liczba recenzentów go zatwierdzi.

Sprawdzanie połączonych elementów roboczych

W przypadku śledzenia zarządzania elementami roboczymi można wymagać skojarzeń między żądaniami ściągnięcia i elementami roboczymi. Łączenie elementów roboczych zapewnia więcej kontekstu zmian i zapewnia, że aktualizacje przechodzą przez proces śledzenia elementów roboczych.

Aby ustawić zasady, w sekcji Zasady gałęzi ustaw opcję Sprawdzanie powiązanych elementów roboczych na Włączone. To ustawienie wymaga, aby elementy robocze były powiązane z żądaniem pull, aby możliwe było połączenie PR. Ustaw ustawienie Opcjonalne , aby wyświetlić ostrzeżenie, gdy nie ma połączonych elementów roboczych, ale zezwalaj na ukończenie żądania ściągnięcia.

Zrzut ekranu przedstawiający wymaganie połączonych elementów roboczych w żądaniach ściągnięcia.

Sprawdź rozwiązywanie komentarzy

Polityka Sprawdzania rozwiązywania komentarzy sprawdza, czy wszystkie komentarze w pull requestach są rozwiązane.

Ustaw zasady rozwiązywania komentarzy dla twojej gałęzi, ustawiając opcję Sprawdź rozwiązanie komentarzy na Włączone. Następnie wybierz, czy zasady mają być wymagane , czy opcjonalne.

Zrzut ekranu przedstawiający sprawdzanie rozwiązania komentarza.

Aby uzyskać więcej informacji na temat pracy z komentarzami żądań łączenia, zobacz Przeglądanie żądań łączenia.

Ogranicz typy scalania

Usługa Azure Repos ma kilka strategii scalania, a domyślnie wszystkie z nich są dozwolone. Można zachować spójną historię gałęzi, wymuszając strategię scalania przy realizacji żądań ściągnięcia.

Ustaw Ogranicz typy scalania na Włączone, aby ograniczyć dozwolone typy scalania w repozytorium.

Zrzut ekranu przedstawiający ograniczanie typów scalania.

  • Scalanie podstawowe (bez szybkiego przekazywania) tworzy zatwierdzenie scalania w gałęzi docelowej, którego rodzicami są gałęzie docelowa i źródłowa.
  • Scalanie typu squash tworzy historię liniową z pojedynczym zatwierdzeniem w gałęzi docelowej ze zmianami z gałęzi źródłowej. Dowiedz się więcej o scalaniu squasha i wpływie na historię gałęzi.
  • Rebase i fast-forward tworzy historię liniową przez ponowne odtwarzanie zatwierdzeń źródłowych w gałęzi docelowej bez zatwierdzenia scalania.
  • Zrebazuj za pomocą zatwierdzenia scalania powtarza zatwierdzenia źródłowe na gałęzi docelowej, a także tworzy zatwierdzenie scalania.

Walidacja kompilacji

Można ustawić zasady, które wymagają pomyślnego zbudowania zmian w żądaniu pull request przed jego zakończeniem. Tworzenie zasad zmniejsza przerwy i pozwala zachować wyniki testów. Tworzenie zasad pomaga nawet wtedy, gdy używasz ciągłej integracji (CI) w gałęziach programowania w celu wczesnego wychwycenia problemów.

Zasady weryfikacji kompilacji kolejkują nową kompilację po utworzeniu nowego żądania ściągnięcia lub wypchnięciu zmian do istniejącego żądania ściągnięcia przeznaczonego dla gałęzi. Polityka budowania ocenia wyniki kompilacji, aby określić, czy pull request może zostać ukończony.

Ważne

Przed określeniem zasad weryfikacji kompilacji należy utworzyć potok kompilacji. Jeśli nie masz potoku, zobacz Tworzenie potoku kompilacji. Wybierz typ kompilacji pasujący do typu projektu.

Aby dodać politykę walidacji kompilacji

  1. + Wybierz przycisk obok pozycji Weryfikacja kompilacji.

    Zrzut ekranu przedstawiający przycisk Dodaj obok pozycji Weryfikacja kompilacji.

  2. Wypełnij formularz Polityka kompilacji:

    Zrzut ekranu przedstawiający ustawienia zasad kompilacji.

    • Wybierz potok kompilacji.

    • Opcjonalnie ustaw filtr Ścieżka. Dowiedz się więcej o filtrach ścieżek w zasadach gałęzi.

    • W obszarze Wyzwalacz wybierz pozycję Automatyczne (za każdym razem, gdy gałąź źródłowa jest aktualizowana) lub Ręcznie.

    • W obszarze Wymaganie dotyczące zasad wybierz pozycję Wymagane lub Opcjonalne. Jeśli wybierzesz pozycję Wymagane, kompilacje muszą zostać ukończone pomyślnie, aby ukończyć żądania ściągnięcia. Wybierz opcję Opcjonalne , aby podać powiadomienie o niepowodzeniu kompilacji, ale nadal zezwalaj na ukończenie żądania ściągnięcia.

    • Ustaw wygaśnięcie buildu, aby upewnić się, że aktualizacje chronionej gałęzi nie powodują problemów ze zmianami w otwartych żądaniach ściągnięcia.

      • Natychmiast po zaktualizowaniu nazwy gałęzi: ta opcja ustawia status zasad kompilacji PR jako niepowodzenie za każdym razem, gdy gałąź jest zaktualizowana, i ustawia kompilację ponownie w kolejce. To ustawienie zapewnia, że zmiany PR budują się pomyślnie, nawet jeśli chroniona gałąź ulegnie zmianie.

        Ta opcja jest najlepsza dla zespołów, których ważne gałęzie mają niewiele zmian. Zespoły pracujące w intensywnie rozwijanych gałęziach mogą uznać za zakłócające oczekiwanie na kompilację za każdym razem, gdy gałąź zostaje zaktualizowana.

      • Po <n> godzinach, jeśli <nazwa> gałęzi została zaktualizowana: ta opcja wygasa bieżący stan zasad, gdy chroniona gałąź zostanie zaktualizowana, jeśli przekazywana kompilacja jest starsza niż wprowadzony próg. Ta opcja jest kompromisem między zawsze a nigdy nie wymagającą kompilacji, gdy chroniona gałąź zostaje zaktualizowana. Ten wybór zmniejsza liczbę kompilacji, gdy chroniona gałąź ma częste aktualizacje.

      • Nigdy: aktualizacje gałęzi chronionej nie zmieniają stanu zasad. Ta wartość zmniejsza liczbę kompilacji, ale może powodować problemy podczas zakończenia pull requestów, które nie zostały ostatnio zaktualizowane.

    • Wprowadź opcjonalną nazwę wyświetlania dla zasad kompilacji. Ta nazwa identyfikuje zasady dotyczące gałęzi na stronie Zasady gałęzi. Jeśli nie określisz nazwy wyświetlanej, polityka używa nazwy potoku kompilacji.

  3. Wybierz pozycję Zapisz.

Gdy autor żądania zatwierdzenia wypchnie zmiany pomyślnie zbudowane, stan polityki zostaje zaktualizowany.

Jeśli masz Natychmiast, gdy <nazwa> gałęzi jest aktualizowana lub po <n> godzinach, jeśli <nazwa> gałęzi została zaktualizowana, stan zasad budowania zostanie zaktualizowany w momencie aktualizacji chronionej gałęzi, o ile poprzednia kompilacja nie jest już prawidłowa.

Sprawdzanie stanu

Usługi zewnętrzne mogą używać API stanu PR do publikowania szczegółowych informacji o stanie twoich PR. Polityka gałęzi dla dodatkowych usług umożliwia tym usługom zewnętrznym uczestnictwo w przepływie pracy pull request i ustanowienie wymagań dotyczących zasad.

Zrzut ekranu przedstawiający opcję Wymagaj zatwierdzenia usług zewnętrznych.

Aby uzyskać instrukcje dotyczące konfigurowania tych zasad, zobacz Konfigurowanie zasad gałęzi dla usługi zewnętrznej.

Automatyczne dołączanie recenzentów kodu

Możesz automatycznie dodawać recenzentów do pull requestów, które zmieniają pliki w określonych katalogach i plikach, lub do wszystkich pull requestów w repozytorium.

  1. Wybierz przycisk obok Automatycznie uwzględnionych recenzentów.

    Zrzut ekranu przedstawiający dodawanie wymaganych recenzentów.

  2. Wypełnij ekran "Dodaj nową zasadę dla recenzenta".

    Zrzut ekranu przedstawiający ekran Dodawanie nowych zasad recenzenta.

    • Dodaj osoby i grupy do recenzentów.

    • Wybierz Opcjonalne, jeśli chcesz automatycznie dodać recenzentów, ale zatwierdzenie nie jest wymagane do ukończenia pull requesta.

      Możesz też wybrać pozycję Wymagane , jeśli żądania ściągnięcia nie zostaną ukończone do czasu:

      • Każda osoba dodana jako recenzent zatwierdza zmiany.
      • Co najmniej jedna osoba w każdej grupie dodanej jako recenzent zatwierdza zmiany.
      • Jeśli wymagana jest tylko jedna grupa, minimalna liczba członków, którą określisz, zatwierdza zmiany.

    • Określ pliki i foldery, które wymagają automatycznie uwzględnionych recenzentów. Pozostawienie tego pola pustym, aby zażądać recenzentów dla wszystkich pull requestów w gałęzi.

    • Wybierz opcję Zezwalaj żądającym zatwierdzanie ich własnych zmian, jeśli autorzy pull requestów mogą głosować, aby zatwierdzić swoje własne pull requesty, aby spełnić te wymagania.

    • Możesz określić komunikat kanału informacyjnego aktywności wyświetlany w żądaniu ściągnięcia.

  3. Wybierz pozycję Zapisz.

Pomijanie zasad gałęzi

W niektórych przypadkach może być konieczne obejście wymagań dotyczących zasad. Pomijanie uprawnień umożliwia wypychanie zmian do gałęzi bezpośrednio lub wykonywanie żądań ściągnięcia, które nie spełniają zasad gałęzi. Możesz przyznać uprawnienia do omijania ograniczeń użytkownikowi lub grupie. Można określić zakres uprawnień do pomijania dla całego projektu, repozytorium lub pojedynczej gałęzi.

Dwa uprawnienia umożliwiają użytkownikom obejście zasad gałęzi na różne sposoby:

  • Pomijanie zasad przy ukończeniu żądań scalenia ma zastosowanie tylko do ukończenia żądania scalenia. Użytkownicy z tym uprawnieniem mogą wykonywać żądania ściągnięcia, nawet jeśli żądania ściągnięcia nie spełniają zasad.

  • Omijanie zasad podczas przesyłania dotyczy przesyłania z repozytoriów lokalnych i edycji w internecie. Użytkownicy z tym uprawnieniem mogą wypychać zmiany bezpośrednio do chronionych gałęzi bez spełnienia wymagań polityki.

Zrzut ekranu przedstawiający uprawnienia do omijania egzekwowania zasad.

Aby uzyskać więcej informacji na temat zarządzania tymi uprawnieniami, zobacz Uprawnienia usługi Git.

Ważne

Należy zachować ostrożność podczas udzielania możliwości pomijania zasad, szczególnie na poziomie repozytorium i projektu. Zasady są podstawą bezpiecznego i zgodnego zarządzania kodem źródłowym.

Filtry ścieżek

Kilka polityk gałęzi oferuje filtry ścieżek. Jeśli filtr ścieżki jest ustawiony, zasady mają zastosowanie tylko do plików, które są zgodne z filtrem ścieżki. Pozostawienie tego pola pustego oznacza, że zasady mają zastosowanie do wszystkich plików w gałęzi.

Można określić ścieżki bezwzględne (ścieżka musi rozpoczynać się od / lub symbolu wieloznacznego) i symbole wieloznaczne. Przykłady:

  • /WebApp/Models/Data.cs
  • /WebApp/*
  • */Models/Data.cs
  • *.cs

Można określić wiele ścieżek przy użyciu ; jako separatora. Przykład:

  • /WebApp/Models/Data.cs;/ClientApp/Models/Data.cs

Ścieżki poprzedzone prefiksem ! są wykluczane, w przeciwnym razie zostałyby uwzględnione. Przykład:

  • /WebApp/*;!/WebApp/Tests/*zawiera wszystkie pliki z wyjątkiem plików w /WebApp/WebApp/Tests
  • !/WebApp/Tests/* określa brak plików, ponieważ nic nie jest uwzględniane jako pierwsze

Kolejność filtrów jest znacząca. Filtry są stosowane od lewej do prawej.

Pytania i odpowiedzi

Czy mogę wypchnąć zmiany bezpośrednio do gałęzi, które mają polityki gałęzi?

Nie można wypychać zmian bezpośrednio do gałęzi z wymaganymi zasadami, chyba że masz uprawnienia do pomijania zasad gałęzi. Zmiany w tych gałęziach można wprowadzać tylko za pośrednictwem pull requestów. Możesz wypchnąć zmiany bezpośrednio do gałęzi, które mają opcjonalne zasady dla gałęzi, jeśli nie mają wymaganych zasad dla gałęzi.

Co to jest autouzupełnianie?

Wnioski o dodanie zmian do gałęzi z skonfigurowanymi zasadami mają przycisk Włącz autouzupełnianie. Wybierz tę opcję, aby automatycznie ukończyć pull request po spełnieniu wszystkich zasad. Autouzupełnianie jest przydatne, gdy nie oczekujesz żadnych problemów ze zmianami.

Kiedy są sprawdzane warunki polityki gałęzi?

Zasady gałęzi są ponownie oceniane na serwerze, gdy właściciele pull request wprowadzają zmiany i kiedy recenzenci głosują. Jeśli zasady wyzwalają kompilację, stan kompilacji zostaje ustawiony na "oczekiwanie", aż kompilacja się zakończy.

Czy można używać definicji kompilacji XAML w zasadach gałęzi?

Nie, nie można używać definicji kompilacji XAML w politykach gałęzi.

Jakich symboli wieloznacznych można używać dla wymaganych recenzentów kodu?

Pojedynczy znak gwiazdki * odpowiada dowolnej liczbie znaków, w tym zarówno ukośnikom /, jak i ukośnikom wstecznym \. Znaki ? zapytania pasują do dowolnego pojedynczego znaku.

Przykłady:

  • *.sql pasuje do wszystkich plików z rozszerzeniem .sql .
  • /ConsoleApplication/* pasuje do wszystkich plików w folderze o nazwie ConsoleApplication.
  • /.gitattributes odpowiada plikowi .gitattributes* w katalogu głównym tego repozytorium.
  • */.gitignore pasuje do dowolnego pliku .gitignore w repozytorium.

Czy w wymaganych ścieżkach recenzenta kodu uwzględniana jest wielkość liter?

Nie, zasady gałęzi nie są uwzględniane wielkości liter.

Jak skonfigurować wielu użytkowników jako wymaganych recenzentów, ale wymagać zatwierdzenia tylko jednego z nich?

Możesz dodać użytkowników do grupy, a następnie dodać grupę jako recenzenta. Każdy członek grupy może następnie zatwierdzić spełnienie wymagań polityki.

Mam uprawnienia do pomijania zasad. Dlaczego nadal widzę niepowodzenia zasad w statusie pull request?

Skonfigurowane zasady są zawsze sprawdzane pod kątem zmian w pull requestach. W przypadku użytkowników z uprawnieniami pomijania zasad zgłaszany stan zasad jest tylko poradą. Jeśli użytkownik posiadający uprawnienia obejścia zatwierdzi, status niepowodzenia nie blokuje ukończenia pull requestu.

Dlaczego nie mogę ukończyć własnych żądań pobrania, gdy opcja "Zezwalaj żądaniom na zatwierdzanie własnych zmian" jest ustawiona?

Zarówno zasada Wymagania minimalnej liczby recenzentów, jak i zasada Automatycznego dołączania recenzentów mają opcję Zezwól wnioskodawcom na zatwierdzanie własnych zmian. W każdej zasadzie ustawienie dotyczy tylko tej zasady. To ustawienie nie ma wpływu na inne zasady.

Na przykład żądanie ściągnięcia ma następujące zasady:

  • Wymagaj minimalnej liczby recenzentów wymaga co najmniej jednego recenzenta.
  • Automatycznie dodani recenzenci wymagają Ciebie lub zespołu, w którym jesteś, jako recenzenta.
  • Automatycznie dołączeni recenzenci mają włączoną opcję Zezwalaj wnioskodawcom na zatwierdzanie własnych zmian.
  • Wymagaj minimalnej liczby recenzentów nie ma włączonej opcji Zezwalaj żądaniom na zatwierdzanie własnych zmian .

W takim przypadku twoje zatwierdzenie spełnia Automatycznie uwzględnieni recenzenci, ale nie Wymagaj minimalnej liczby recenzentów, więc nie można ukończyć pull request.

Mogą również istnieć inne zasady, takie jak Zakaz dla najnowszego wprowadzającego zatwierdzania własnych zmian, co uniemożliwia zatwierdzenie ich własnych zmian, nawet jeśli opcja Zezwalaj żądającym na zatwierdzanie własnych zmian jest ustawiona.

Co się stanie, gdy ścieżka w filtrach ścieżek nie zaczyna się od / lub od symbolu wieloznacznego?

Ścieżka w filtrze ścieżki, która nie zaczyna się od / lub z symbolem wieloznacznym, nie ma wpływu, a filtr ścieżki działa tak, jakby ta ścieżka nie była określona. Taka ścieżka nie może być zgodna z bezwzględną ścieżką pliku, która zaczyna się od /.