Grenprinciper och inställningar

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Grenprinciper hjälper team att skydda sina viktiga utvecklingsgrenar . Principer tillämpar teamets standarder för kodkvalitet och ändringshantering. I den här artikeln beskrivs hur du ställer in och hanterar grenprinciper. En översikt över alla principer och inställningar för lagringsplats och gren finns i Inställningar och principer för Git-lagringsplats.

En gren som har nödvändiga principer konfigurerade kan inte tas bort och kräver pull-begäranden (PR) för alla ändringar.

Förutsättningar

  • Om du vill ange grenprinciper måste du vara medlem i säkerhetsgruppen Projektadministratörer eller ha behörigheter för redigeringsprinciper på lagringsplatsnivå. Mer information finns i Ange Behörigheter för Git-lagringsplats.

  • Om du vill använda Azure DevOps CLI az repos policy-kommandon för att hantera grenprinciper följer du stegen i Kom igång med Azure DevOps CLI.

  • Om du vill ange grenprinciper måste du vara medlem i säkerhetsgruppen Projektadministratörer eller ha behörigheter för redigeringsprinciper på lagringsplatsnivå. Mer information finns i Ange Behörigheter för Git-lagringsplats.

Konfigurera grenprinciper

Om du vill hantera grenprinciper väljer du Repos Branch (Lagringsgrenar>) för att öppna sidan Grenar i webbportalen.

Skärmbild som visar menyalternativet Grenar.

Du kan också komma åt förgreningsprincipinställningar med Project Inställningar> Repository>Policies>Branch Policies<>Branch Name.>

Grenar som har principer visar en principikon. Du kan välja ikonen för att gå direkt till grenens principinställningar.

Om du vill ange grenprinciper letar du upp den gren som du vill hantera. Du kan bläddra i listan eller söka efter din gren i rutan Sök grennamn uppe till höger.

Välj ikonen Fler alternativ bredvid grenen och välj sedan Grenprinciper på snabbmenyn.

Skärmbild som visar Öppna förgreningsprinciperna från snabbmenyn.

Leta upp din gren på sidan. Du kan bläddra i listan eller söka efter din gren med hjälp av rutan Sök alla grenar i det övre högra hörnet.

Skärmbild som visar sidan Grenar.

Välj knappen ... . Välj Grenprinciper på snabbmenyn.

Skärmbild som visar Öppna förgreningsprinciperna från snabbmenyn.

Konfigurera principer på grenens inställningssida. Se följande avsnitt för beskrivningar och instruktioner för varje principtyp.

Konfigurera dina principer på sidan Principer . Se följande avsnitt för beskrivningar av varje principtyp. Välj Spara ändringar för att tillämpa den nya principkonfigurationen.

Skärmbild som visar fliken Principer.

Kräv ett minsta antal granskare

Kodgranskningar är viktiga för programutvecklingsprojekt. För att säkerställa att team granskar och godkänner pr-begäranden kan du kräva godkännande från ett minsta antal granskare. Den grundläggande principen kräver att ett angivet antal granskare godkänner koden, utan avvisanden.

Om du vill ange principen under Avdelningsprinciper anger du Kräv ett minsta antal granskare till På. Ange det antal granskare som krävs och välj något av följande alternativ:

Skärmbild som visar principen Aktivera principen Kräv kodgranskning.

  • Välj Tillåt begärande att godkänna sina egna ändringar så att en PR-skapare kan rösta om dess godkännande. Annars kan skaparen fortfarande rösta Godkänn på PR, men deras röst räknas inte mot det minsta antalet granskare.

  • Välj Förhindra att den senaste push-användaren godkänner sina egna ändringar för att framtvinga uppdelning av uppgifter. Som standard kan alla som har push-behörighet på källgrenen både lägga till incheckningar och rösta om PR-godkännande. Om du väljer det här alternativet räknas inte den senaste pusherns röst, även om de vanligtvis kan godkänna sina egna ändringar.

  • Välj Tillåt slutförande även om vissa granskare röstar för att vänta eller avvisa för att tillåta pr-slutförande även om vissa granskare röstar emot godkännande. Det minsta antalet granskare måste fortfarande godkänna.

  • Under När nya ändringar skickas:
    • Välj Kräv minst ett godkännande för den senaste iterationen för att kräva minst en godkännandeomröstning för den senaste ändringen av källgrenen.
    • Välj Återställ alla godkännanderöster (återställer inte röster för att avvisa eller vänta) för att ta bort alla godkännanderöster, men behåll röster för att avvisa eller vänta när källgrenen ändras.
    • Välj Återställ alla röster för kodgranskare för att ta bort alla granskarröster när källgrenen ändras, inklusive röster för att godkänna, avvisa eller vänta.
  • Under När nya ändringar skickas:
    • Välj Kräv minst ett godkännande för varje iteration för att kräva minst en godkännanderöst för den senaste ändringen av källgrenen. Användarens godkännande räknas inte mot tidigare icke godkända iteration som pushats av användaren. Därför måste ytterligare godkännande av den senaste iterationen göras av en annan användare. Kräv minst ett godkännande för varje iteration som är tillgänglig i Azure DevOps Server 2022.1 och senare.
    • Välj Kräv minst ett godkännande för den senaste iterationen för att kräva minst en godkännandeomröstning för den senaste ändringen av källgrenen.
    • Välj Återställ alla godkännanderöster (återställer inte röster för att avvisa eller vänta) för att ta bort alla godkännanderöster, men behåll röster för att avvisa eller vänta när källgrenen ändras.
    • Välj Återställ alla röster för kodgranskare för att ta bort alla granskarröster när källgrenen ändras, inklusive röster för att godkänna, avvisa eller vänta.

Markera rutan Kräv kodgranskningar

  • Om Begärande kan godkänna sina egna ändringar inte har valts kan skaparen av pull-begäran fortfarande rösta Godkänn på sin pull-begäran, men deras röst räknas inte mot det minsta antalet granskare.
  • Om någon granskare avvisar ändringarna kan pull-begäran inte slutföras om du inte väljer Tillåt slutförande även om vissa granskare röstar för att vänta eller avvisa.
  • Du kan återställa röster för kodgranskare när nya ändringar skickas till källgrenen. Välj Återställ röster för kodgranskare när det finns nya ändringar.

Om alla andra principer godkänns kan skaparen slutföra pr när det begärda antalet granskare godkänner den.

Sök efter länkade arbetsobjekt

För spårning av arbetsobjektshantering kan du kräva associationer mellan pr och arbetsobjekt. Länkning av arbetsobjekt ger mer kontext för ändringar och säkerställer att uppdateringarna går igenom spårningsprocessen för arbetsobjekt.

Om du vill ange principen under Avdelningsprinciper anger du Sök efter länkade arbetsobjekt till På. Den här inställningen kräver att arbetsobjekten är länkade till en PR för att pr ska slås samman. Gör inställningen Valfri för att varna när det inte finns några länkade arbetsobjekt, men tillåt slutförande av pull-begäran.

Skärmbild av krav på länkade arbetsobjekt i pull-begäranden.

Kräv länkade arbetsobjekt i dina pull-begäranden

Sök efter kommentarsmatchning

Policyn Check for comment resolution kontrollerar om alla PR-kommentarer har lösts.

Konfigurera en policy för kommentarsmatchning för din gren genom att ange Sök efter kommentarsmatchning till På. Välj sedan om du vill göra principen Obligatorisk eller Valfri.

Sök efter kommentarsmatchning

Mer information om hur du arbetar med pull-begärandekommentärer finns i Granska pull-begäranden.

Konfigurera en policy för kommentarsmatchning för din gren genom att välja Sök efter kommentarsmatchning.

Sök efter kommentarsmatchning

Mer information om hur du arbetar med pull-begärandekommentärer finns i Granska pull-begäranden.

Begränsa sammanslagningstyper

Azure Repos har flera sammanslagningsstrategier, och som standard tillåts alla. Du kan upprätthålla en konsekvent grenhistorik genom att framtvinga en sammanslagningsstrategi för slutförande av PR.

Ange Begränsa sammanslagningstyper till På för att begränsa vilka sammanslagningstyper som ska tillåtas på lagringsplatsen.

Begränsa sammanslagningstyper

  • Grundläggande sammanslagning (ingen snabbsnabbning) skapar en sammanslagningsincheckning i målet vars överordnade objekt är mål- och källgrenarna.
  • Squashsammanslagning skapar en linjär historik med en enda incheckning i målgrenen med ändringarna från källgrenen. Läs mer om squashsammanslagningen och hur den påverkar grenhistoriken.
  • Ombasera och snabbspola framåt skapar en linjär historik genom att spela upp källincheckningar på målgrenen utan kopplingsincheckning.
  • Ombasera med sammanslagningsincheckning spelar upp källincheckningarna på målet och skapar även en sammanslagningsincheckning.

Kommentar

Den här funktionen är tillgänglig för Azure DevOps Server 2020 och senare versioner.

Framtvinga en sammanslagningsstrategi

Upprätthålla en konsekvent grenhistorik genom att framtvinga en sammanslagningsstrategi när en pull-begäran slutförs. Välj Framtvinga en sammanslagningsstrategi och välj ett alternativ för att kräva att pull-begäranden slås samman med den strategin.

Ange kopplingskrav

  • Ingen snabbkoppling – Det här alternativet sammanfogar källgrenens incheckningshistorik när pull-begäran stängs och skapar en sammanslagningsbegäran i målgrenen.
  • Squashsammanslagning – Slutför alla pull-begäranden med en squashsammanslagning och skapa en enda incheckning i målgrenen med ändringarna från källgrenen. Läs mer om squashsammanslagningen och hur den påverkar din grenhistorik.

Byggverifiering

Du kan ange en princip som kräver att PR-ändringar skapas innan pr kan slutföras. Skapa principer minskar pauser och håller testresultaten klara. Byggprinciper hjälper även om du använder kontinuerlig integrering (CI) på dina utvecklingsgrenar för att fånga upp problem tidigt.

En byggvalideringsprincip köar en ny version när en ny PR skapas eller ändringar skickas till en befintlig PR som riktar sig mot grenen. Byggprincipen utvärderar byggresultatet för att avgöra om pr kan slutföras.

Viktigt!

Innan du anger en byggverifieringsprincip måste du ha en bygg-pipeline. Om du inte har någon pipeline kan du läsa Skapa en byggpipeline. Välj vilken typ av bygge som matchar din projekttyp.

Så här lägger du till en byggverifieringsprincip

  1. + Välj knappen bredvid Skapa validering.

    Skärmbild som visar knappen Lägg till bredvid Build-validering.

  2. Fyll i formuläret Ange byggprincip :

    Skapa principinställningar

    • Välj bygg-pipelinen.

    • Du kan också ange ett sökvägsfilter. Läs mer om sökvägsfilter i grenprinciper.

    • Under Utlösare väljer du Automatisk (när källgrenen uppdateras) eller Manuell.

    • Under Principkrav väljer du Obligatoriskt eller Valfritt. Om du väljer Obligatoriskt måste byggen slutföras för att slutföra PRs. Välj Valfritt om du vill ange ett meddelande om byggfelet men ändå tillåta att PR:er slutförs.

    • Ange ett byggdatum för att se till att uppdateringar av din skyddade gren inte bryter ändringar för öppna PR:er.

      • Omedelbart när <grennamnet> uppdateras: Det här alternativet anger status för PR-byggprincipen till misslyckad när grenen uppdateras och returnerar en version på nytt. Den här inställningen säkerställer att PR-ändringarna skapas även om den skyddade grenen ändras.

        Det här alternativet passar bäst för team vars viktiga grenar har få ändringar. Team som arbetar i upptagna utvecklingsgrenar kan få det störande att vänta på ett bygge varje gång grenen uppdateras.

      • Efter <n> timmar om <grennamnet> har uppdaterats: Det här alternativet upphör att gälla den aktuella principstatusen när den skyddade grenen uppdateras om den övergående versionen är äldre än det tröskelvärde som du anger. Det här alternativet är en kompromiss mellan att alltid eller aldrig kräva en version när den skyddade grenen uppdateras. Det här valet minskar antalet versioner när den skyddade grenen har frekventa uppdateringar.

      • Aldrig: Uppdateringar till den skyddade grenen ändrar inte principstatusen. Det här värdet minskar antalet versioner, men kan orsaka problem när du slutför prs som inte har uppdaterats nyligen.

    • Ange ett valfritt visningsnamn för den här byggprincipen. Det här namnet identifierar principen på sidan Grenprinciper . Om du inte anger något visningsnamn använder principen namnet på bygg-pipelinen.

  3. Välj Spara.

När PR-ägaren push-överför ändringar som har skapats uppdateras principstatusen.

Om du har ett Omedelbart när <grennamnet> uppdateras eller Efter <n> timmar om <grennamnet> har uppdaterats , uppdateras principstatusen när den skyddade grenen uppdateras, om den tidigare versionen inte längre är giltig.

Kommentar

Den här funktionen är tillgänglig för Azure DevOps Server 2020 och senare versioner.

Ange en princip som kräver ändringar i en pull-begäran för att skapa med den skyddade grenen innan pull-begäran kan slutföras. Skapa principer minskar pauser och håller testresultaten klara. Byggprinciper hjälper även om du använder kontinuerlig integrering (CI) på dina utvecklingsgrenar för att fånga upp problem tidigt.

Om en byggverifieringsprincip är aktiverad placeras en ny version i kö när antingen en ny pull-begäran skapas eller om ändringar skickas till en befintlig pull-begäran som riktar sig mot grenen. Byggprincipen utvärderar sedan resultatet av bygget för att avgöra om pull-begäran kan slutföras.

Viktigt!

Innan du anger en byggverifieringsprincip måste du ha en byggdefinition. Om du inte har någon läser du Skapa en byggdefinition och väljer den typ av bygge som matchar din projekttyp.

Lägg till byggprincip

Välj Lägg till byggprincip och konfigurera dina alternativ i Lägg till byggprincip.

Skapa principinställningar

  1. Välj build-definitionen.

  2. Välj typ av utlösare. Välj Automatisk (när källgrenen uppdateras) eller Manuell.

  3. Välj principkravet. Om du väljer Krävs måste byggen slutföras för att slutföra pull-begäranden. Välj Valfritt om du vill ange ett meddelande om byggfelet men ändå tillåta att pull-begäranden slutförs.

  4. Ange ett versionsdatum för att se till att uppdateringar av din skyddade gren inte bryter ändringar för öppna pull-begäranden.

    • Omedelbart när branch name uppdateras: Det här alternativet anger statusen för byggprincipen i en pull-begäran till misslyckad när den skyddade grenen uppdateras. Skicka ett bygge på nytt för att uppdatera byggstatusen. Den här inställningen säkerställer att ändringarna i pull-begäranden skapas även när den skyddade grenen ändras. Det här alternativet passar bäst för team som har viktiga grenar med en lägre volym av ändringar. Team som arbetar i upptagna utvecklingsgrenar kan få det störande att vänta tills en version har slutförts varje gång den skyddade grenen uppdateras.
    • Efter n timmar om branch name har uppdaterats: Det här alternativet upphör att gälla den aktuella principstatusen när den skyddade grenen uppdateras om den övergående versionen är äldre än det angivna tröskelvärdet. Det här alternativet är en kompromiss mellan att alltid kräva en version när den skyddade grenen uppdateras och aldrig kräver någon. Det här valet är utmärkt för att minska antalet versioner när din skyddade gren har frekventa uppdateringar.
    • Aldrig: Uppdateringar till den skyddade grenen ändrar inte principstatusen. Det här värdet minskar antalet versioner för din gren. Det kan orsaka problem när pull-begäranden som inte har uppdaterats nyligen stängs.

  5. Ange ett valfritt visningsnamn för den här byggprincipen. Det här namnet identifierar principen på sidan Grenprinciper . Om du inte anger något visningsnamn använder principen versionsdefinitionsnamnet.

  6. Välj Spara.

När ägaren push-överför ändringar som har skapats uppdateras principstatusen. Om du har en Omedelbart när branch name uppdateras eller Efter n timmar om branch name du har valt en uppdaterad byggprincip uppdateras principstatusen när den skyddade grenen uppdateras om den senaste versionen inte längre är giltig.

Statuskontroller

Externa tjänster kan använda PR-status-API:et för att publicera detaljerad status till dina pr-flöden. Med grenprincipen för ytterligare tjänster kan dessa tjänster från tredje part delta i PR-arbetsflödet och upprätta principkrav.

Kräv att externa tjänster godkänns

Anvisningar om hur du konfigurerar den här principen finns i Konfigurera en grenprincip för en extern tjänst.

Kräv godkännande från externa tjänster

Externa tjänster kan använda PR-status-API:et för att publicera detaljerad status till dina pr-flöden. Grenprincipen för ytterligare tjänster ger dessa tjänster från tredje part möjlighet att delta i PR-arbetsflödet och upprätta principkrav.

Kräv att externa tjänster godkänns

Anvisningar om hur du konfigurerar den här principen finns i Konfigurera en grenprincip för en extern tjänst.

Inkludera kodgranskare automatiskt

Du kan automatiskt lägga till granskare till pull-begäranden som ändrar filer i specifika kataloger och filer, eller till alla pull-begäranden på en lagringsplats.

  1. + Välj knappen bredvid Automatiskt inkluderade granskare.

    Skärmbild som visar Lägg till nödvändiga granskare.

  2. Fyll i skärmen Lägg till ny granskarprincip .

    Skärmbild som visar skärmen Lägg till ny granskarprincip.

    • Lägg till personer och grupper i Granskare.

    • Välj Valfritt om du vill lägga till granskare automatiskt, men inte kräva deras godkännande för att slutföra pull-begäran.

      Eller välj Obligatoriskt om pull-begäranden inte kan slutföras förrän:

      • Varje individ som läggs till som granskare godkänner ändringarna.
      • Minst en person i varje grupp som läggs till som granskare godkänner ändringarna.
      • Om endast en grupp krävs godkänner det minsta antalet medlemmar som du anger ändringarna.

    • Ange de filer och mappar som kräver automatiskt inkluderade granskare. Lämna fältet tomt för att kräva granskarna för alla pull-begäranden i grenen.

    • Välj Tillåt begärande att godkänna sina egna ändringar om pull-begärandeägare kan rösta för att godkänna sina egna pull-begäranden för att uppfylla den här principen.

    • Du kan ange ett aktivitetsflödesmeddelande som visas i pull-begäran.

  3. Välj Spara.

Kommentar

Den här funktionen är tillgänglig för Azure DevOps Server 2020 och senare versioner.

Välj granskare för specifika kataloger och filer på lagringsplatsen.

Ange sökvägen och nödvändiga granskare

Dessa granskare läggs automatiskt till i pull-begäranden som ändrar filer längs dessa sökvägar. Du kan också ange ett meddelande om aktivitetsfeed.

Lägga till automatiska granskare

Om du väljer Obligatorisk kan pull-begäran inte slutföras förrän:

  • Varje användare som läggs till som granskare för sökvägen godkänner ändringarna.
  • Minst en person i varje grupp som läggs till i sökvägen godkänner ändringarna.
  • Antalet granskare som har angetts för varje grupp som läggs till i sökvägen godkänner ändringarna.

Nödvändiga granskare läggs till automatiskt

Välj Valfritt om du vill lägga till granskare automatiskt, men inte kräva deras godkännande för att slutföra pull-begäran.

Du kan välja Begärare kan godkänna sina egna ändringar.

När alla nödvändiga granskare godkänner koden kan du slutföra pull-begäran.

Status för pull-begäran visar att granskare har godkänt

Kringgå grenprinciper

I vissa fall kan du behöva kringgå principkraven. Med förbikopplingsbehörigheter kan du skicka ändringar till en gren direkt eller slutföra pull-begäranden som inte uppfyller grenprinciper. Du kan bevilja förbikopplingsbehörigheter till en användare eller grupp. Du kan kringgå behörigheter till ett helt projekt, en lagringsplats eller en enda gren.

Med två behörigheter kan användare kringgå grenprinciper på olika sätt:

  • Kringgå principer när du slutför pull-begäranden gäller endast för slutförande av pull-begäranden. Användare med den här behörigheten kan slutföra pull-begäranden även om pull-begäranden inte uppfyller principerna.

  • Kringgå principer vid push-överföring gäller push-överföring från lokala lagringsplatser och ändringar som görs på webben. Användare med den här behörigheten kan skicka ändringar direkt till skyddade grenar utan att uppfylla principkraven.

Skärmbild som visar behörigheter för att kringgå principtillämpning.

Mer information om hur du hanterar dessa behörigheter finns i Git-behörigheter.

I TFS 2015 till TFS 2018 Update 2 tillåter behörigheten Undanta från principtillämpning användare med den här behörigheten att utföra följande åtgärder:

  • När du slutför en pull-begäran kan du välja att åsidosätta principer och slutföra en pull-begäran även om den aktuella uppsättningen förgreningsprinciper inte uppfylls.
  • Push-överför direkt till en gren även om grenen har angett grenprinciper. Observera att när en användare med den här behörigheten gör en push-överföring som skulle åsidosätta grenprincipen kringgår push-överföringen automatiskt grenprincipen utan steg eller varning.

Viktigt!

Var försiktig när du ger möjlighet att kringgå principer, särskilt på lagringsplats- och projektnivå. Principer är en hörnsten i säker och kompatibel källkodshantering.

Sökvägsfilter

Flera grenprinciper erbjuder sökvägsfilter. Om ett sökvägsfilter har angetts gäller principen endast för filer som matchar sökvägsfiltret. Om du lämnar det här fältet tomt innebär det att principen gäller för alla filer i grenen.

Du kan ange absoluta sökvägar (sökvägen måste starta antingen med / eller ett jokertecken) och jokertecken. Exempel:

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

Du kan ange flera sökvägar med som ; avgränsare. Exempel:

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

Sökvägar som föregås av ! utesluts om de annars skulle inkluderas. Exempel:

  • /WebApp/*;!/WebApp/Tests/* innehåller alla filer utom /WebApp filer i /WebApp/Tests
  • !/WebApp/Tests/* anger inga filer, eftersom ingenting inkluderas först

Filterordningen är betydande. Filter tillämpas från vänster till höger.

Frågor och svar

Kan jag skicka ändringar direkt till grenar som har grenprinciper?

Du kan inte push-överföra ändringar direkt till grenar som har nödvändiga förgreningsprinciper om du inte har behörighet att kringgå grenprinciper. Ändringar i dessa grenar kan endast göras via pull-begäranden. Du kan skicka ändringar direkt till grenar som har valfria grenprinciper, om de inte har några nödvändiga grenprinciper.

Vad är automatisk komplettering?

Hämta begäranden till grenar med konfigurerade grenprinciper har knappen Ange automatisk komplettering . Välj det här alternativet om du vill slutföra pull-begäran automatiskt när den uppfyller alla principer. Automatisk komplettering är användbart när du inte förväntar dig några problem med dina ändringar.

När kontrolleras villkor för grenprinciper?

Grenprinciper omvärderas på servern när pull-begärandeägare push-överför ändringar och när granskare röstar. Om en princip utlöser en version ställs byggstatusen in på att vänta tills bygget har slutförts.

Kan jag använda XAML-versionsdefinitioner i grenprinciper?

Nej, du kan inte använda XAML-byggdefinitioner i grenprinciper.

Vilka jokertecken kan jag använda för kodgranskare som krävs?

Enstaka asterisker * matchar valfritt antal tecken, inklusive både snedstreck / och snedstreck \. Frågetecken ? matchar ett enskilt tecken.

Exempel:

  • *.sql matchar alla filer med tillägget .sql .
  • /ConsoleApplication/* matchar alla filer under mappen ConsoleApplication.
  • /.gitattributesmatchar .gitattributes-filen i roten på lagringsplatsen.
  • */.gitignore matchar alla .gitignore-filer på lagringsplatsen.

Är de nödvändiga sökvägarna för kodgranskare skiftlägeskänsliga?

Nej, grenprinciper är inte skiftlägeskänsliga.

Hur konfigurerar jag flera användare som nödvändiga granskare, men behöver bara en av dem för att godkänna?

Du kan lägga till användarna i en grupp och sedan lägga till gruppen som granskare. Alla medlemmar i gruppen kan sedan godkänna för att uppfylla principkravet.

Jag har behörighet att kringgå principer. Varför ser jag fortfarande principfel i statusen för pull-begäran?

Konfigurerade principer utvärderas alltid för pull-begärandeändringar. För användare som har behörighet att kringgå principer är den rapporterade principstatusen endast rådgivande. Om användaren med förbikopplingsbehörigheter godkänner blockeras inte slutförande av pull-begäran.

Varför kan jag inte slutföra mina egna pull-begäranden när "Tillåt begäranden att godkänna sina egna ändringar har angetts"?

Både principen Kräv ett minsta antal granskare och principen Automatiskt inkluderade granskare har alternativ för att tillåta begärande att godkänna sina egna ändringar. I varje princip gäller inställningen endast för den principen. Inställningen påverkar inte den andra principen.

Din pull-begäran har till exempel följande principer inställda:

  • Kräv minst ett antal granskare kräver minst en granskare.
  • Automatiskt inkluderade granskare kräver att du eller ett team du är i som granskare.
  • Automatiskt inkluderade granskare har Tillåt begäranden att godkänna sina egna ändringar aktiverade.
  • Kräv att ett minsta antal granskare inte har Tillåt begärande att godkänna sina egna ändringar aktiverade.

I det här fallet uppfyller ditt godkännande automatiskt inkluderade granskare, men inte Kräv ett minsta antal granskare, så du kan inte slutföra pull-begäran.

Det kan också finnas andra principer, till exempel Förhindra att den senaste push-användaren godkänner sina egna ändringar, som hindrar dig från att godkänna dina egna ändringar även om Tillåt begäranden att godkänna sina egna ändringar har angetts.

Vad händer när sökvägen i sökvägsfilter inte börjar med / eller med jokertecken?

Sökvägen i sökvägsfilter som varken börjar med / eller med ett jokertecken har ingen effekt, och sökvägsfiltret utvärderas som om sökvägen inte angavs. Det beror på att en sådan sökväg inte kan matcha den / absoluta filsökvägen som börjar med.