Vertakkingsbeleid en -instellingen

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Met vertakkingsbeleid kunnen teams hun belangrijke takken van ontwikkeling beschermen. Beleidsregels dwingen de codekwaliteits- en wijzigingsbeheerstandaarden van uw team af. In dit artikel wordt beschreven hoe u vertakkingsbeleid instelt en beheert. Zie Instellingen en beleidsregels voor Git-opslagplaatsen voor een overzicht van alle beleidsregels en instellingen voor opslagplaatsen en vertakkingen.

Een vertakking waarvoor vereist beleid is geconfigureerd, kan niet worden verwijderd en vereist pull-aanvragen (PULL's) voor alle wijzigingen.

Vereisten

  • Als u vertakkingsbeleid wilt instellen, moet u lid zijn van de beveiligingsgroep project Beheer istrators of machtigingen voor beleid bewerken op opslagplaatsniveau hebben. Zie Machtigingen voor Git-opslagplaatsen instellen voor meer informatie.

Vertakkingsbeleid configureren

Als u vertakkingsbeleid wilt beheren, selecteert u Opslagplaatsen>vertakkingen om de pagina Vertakkingen te openen in de webportal.

Schermopname van het menu-item Branches.

U kunt ook instellingen voor vertakkingsbeleid openen met Project Instellingen> Repository>Policies><>Branch Branch Name.>

Vertakkingen met beleidsregels geven een beleidspictogram weer. U kunt het pictogram selecteren om rechtstreeks naar de beleidsinstellingen van de vertakking te gaan.

Als u vertakkingsbeleid wilt instellen, zoekt u de vertakking die u wilt beheren. U kunt in de lijst bladeren of naar uw vertakking zoeken in het vak Naam van de zoekbranch rechtsboven.

Selecteer het pictogram Meer opties naast de vertakking en selecteer vervolgens Branch-beleid in het contextmenu.

Schermopname van Het vertakkingsbeleid openen in het contextmenu.

Zoek uw vertakking op de pagina. U kunt door de lijst bladeren of u kunt zoeken naar uw vertakking met behulp van het vak Alle vertakkingen zoeken in de rechterbovenhoek.

Schermopname van de pagina Branches.

Selecteer de knop ... . Selecteer Vertakkingsbeleid in het contextmenu.

Schermopname van Het vertakkingsbeleid openen in het contextmenu.

Configureer beleidsregels op de pagina instellingen van de vertakking. Zie de volgende secties voor beschrijvingen en instructies voor elk beleidstype.

Configureer uw beleid op de pagina Beleid . Zie de volgende secties voor beschrijvingen van elk beleidstype. Selecteer Wijzigingen opslaan om de nieuwe beleidsconfiguratie toe te passen.

Schermopname van het tabblad Beleid.

Een minimum aantal revisoren vereisen

Codebeoordelingen zijn belangrijk voor softwareontwikkelingsprojecten. Om ervoor te zorgen dat teams pull-aanvragen beoordelen en goedkeuren, kunt u goedkeuring van een minimum aantal revisoren vereisen. Het basisbeleid vereist dat een opgegeven aantal revisoren de code goedkeurt, zonder afwijzingen.

Als u het beleid wilt instellen, stelt u onder Vertakkingsbeleid een minimum aantal revisoren vereisen in op Aan. Voer het vereiste aantal revisoren in en selecteer een van de volgende opties:

Schermopname van het beleid Codebeoordelingen vereisen inschakelen.

  • Selecteer Aanvragers toestaan om hun eigen wijzigingen goed te keuren, zodat de maker van een pull-aanvraag kan stemmen op de goedkeuring ervan. Anders kan de maker nog steeds goedkeuren voor de pull-aanvraag, maar zijn stem niet meegeteld voor het minimale aantal revisoren.

  • Selecteer Verbieden dat de meest recente pusher hun eigen wijzigingen goedkeurt om scheiding van taken af te dwingen. Standaard kan iedereen met pushmachtigingen voor de bronbranch doorvoeringen toevoegen en stemmen op goedkeuring van pull-aanvraag. Als u deze optie selecteert, betekent dit dat de stem van de meest recente pusher niet telt, zelfs niet als ze hun eigen wijzigingen gewoonlijk kunnen goedkeuren.

  • Selecteer Voltooiing toestaan, zelfs als sommige revisoren stemmen om te wachten of af te wijzen om pr-voltooiing toe te staan, zelfs als sommige revisoren tegen goedkeuring stemmen. Het minimale aantal revisoren moet nog steeds worden goedgekeurd.

  • Onder Wanneer nieuwe wijzigingen worden gepusht:
    • Selecteer Ten minste één goedkeuring vereisen voor de laatste iteratie om ten minste één goedkeuringsstem te vereisen voor de laatste wijziging van de bronvertakking.
    • Selecteer Alle goedkeuringsstemmen opnieuw instellen (stelt stemmen niet opnieuw in om te weigeren of te wachten) om alle goedkeuringsstemmen te verwijderen, maar houd stemmen om af te wijzen of te wachten, wanneer de bronbranch verandert.
    • Selecteer Alle stemmen van de coderevisor opnieuw instellen om alle revisorstemmen te verwijderen wanneer de bronbranch verandert, inclusief stemmen die moeten worden goedgekeurd, geweigerd of gewacht.
  • Onder Wanneer nieuwe wijzigingen worden gepusht:
    • Selecteer Ten minste één goedkeuring vereisen voor elke iteratie om ten minste één goedkeuringsstem voor de laatste wijziging van de bronvertakking te vereisen. De goedkeuring van de gebruiker wordt niet meegeteld bij een eerdere niet-goedgekeurde iteratie die door die gebruiker wordt gepusht. Als gevolg hiervan is aanvullende goedkeuring vereist voor de laatste iteratie door een andere gebruiker. Er is ten minste één goedkeuring vereist voor elke iteratie die beschikbaar is in Azure DevOps Server 2022.1 en hoger.
    • Selecteer Ten minste één goedkeuring vereisen voor de laatste iteratie om ten minste één goedkeuringsstem te vereisen voor de laatste wijziging van de bronvertakking.
    • Selecteer Alle goedkeuringsstemmen opnieuw instellen (stelt stemmen niet opnieuw in om te weigeren of te wachten) om alle goedkeuringsstemmen te verwijderen, maar houd stemmen om af te wijzen of te wachten, wanneer de bronbranch verandert.
    • Selecteer Alle stemmen van de coderevisor opnieuw instellen om alle revisorstemmen te verwijderen wanneer de bronbranch verandert, inclusief stemmen die moeten worden goedgekeurd, geweigerd of gewacht.

Schakel het selectievakje Codebeoordelingen vereisen in

  • Als aanvragers hun eigen wijzigingen kunnen goedkeuren niet is geselecteerd, kan de maker van de pull-aanvraag nog steeds stemmen op Goedkeuren op hun pull-aanvraag, maar hun stem telt niet mee voor het minimum aantal revisoren.
  • Als een revisor de wijzigingen weigert, kan de pull-aanvraag alleen worden voltooid als u Voltooiing toestaan selecteert , zelfs als sommige revisoren stemmen om te wachten of af te wijzen.
  • U kunt de stemmen van de coderevisor opnieuw instellen wanneer nieuwe wijzigingen naar de bronbranch worden gepusht. Selecteer Revisorstemmen voor code opnieuw instellen wanneer er nieuwe wijzigingen zijn.

Als alle andere beleidsregels worden doorgegeven, kan de maker de pull-aanvraag voltooien wanneer het vereiste aantal revisoren dit goedkeurt.

Controleren op gekoppelde werkitems

Voor het bijhouden van werkitems kunt u koppelingen tussen PULL's en werkitems vereisen. Het koppelen van werkitems biedt meer context voor wijzigingen en zorgt ervoor dat updates het traceringsproces van uw werkitems doorlopen.

Als u het beleid wilt instellen, stelt u onder Vertakkingsbeleid Controleren op gekoppelde werkitems in op Aan. Voor deze instelling moeten werkitems worden gekoppeld aan een pull-aanvraag om de pull-aanvraag samen te voegen. Voer de instelling Optioneel in om te waarschuwen wanneer er geen gekoppelde werkitems zijn, maar toestaan dat de pull-aanvraag is voltooid.

Schermopname van het vereisen van gekoppelde werkitems in pull-aanvragen.

Gekoppelde werkitems in uw pull-aanvragen vereisen

Controleren op resolutie van opmerkingen

Het beleid Controleren op oplossing van opmerkingen controleert of alle pr-opmerkingen zijn opgelost.

Configureer een oplossingsbeleid voor opmerkingen voor uw vertakking door Controleren op resolutie van opmerkingen in te stellen op Aan. Selecteer vervolgens of u het beleid vereist of optioneel wilt maken.

Controleren op resolutie van opmerkingen

Zie Pull-aanvragen controleren voor meer informatie over het werken met opmerkingen bij pull-aanvragen.

Configureer een beleid voor het oplossen van opmerkingen voor uw vertakking door Controleren op oplossing van opmerkingen te selecteren.

Controleren op resolutie van opmerkingen

Zie Pull-aanvragen controleren voor meer informatie over het werken met opmerkingen bij pull-aanvragen.

Samenvoegtypen beperken

Azure-opslagplaatsen hebben verschillende samenvoegstrategieën en standaard zijn ze allemaal toegestaan. U kunt een consistente vertakkingsgeschiedenis onderhouden door een samenvoegstrategie af te dwingen voor het voltooien van pull-aanvragen.

Stel samenvoegtypen in op Aan om te beperken welke samenvoegtypen in uw opslagplaats moeten worden toegestaan.

Samenvoegtypen beperken

  • Met eenvoudige samenvoeging (geen snelle doorstuurbewerking) wordt een samenvoegdoorvoering gemaakt in het doel waarvan de ouders het doel en de bronvertakkingen zijn.
  • Squash merge maakt een lineaire geschiedenis met één doorvoering in de doelbranch met de wijzigingen van de bronbranch. Meer informatie over het samenvoegen van squashs en hoe het van invloed is op de vertakkingsgeschiedenis.
  • Rebase en fast-forward maakt een lineaire geschiedenis door brondoorvoeringen opnieuw af te spelen op de doelvertakking zonder samenvoegdoorvoering.
  • Rebase met samenvoeging doorvoert de brondoorvoeringen opnieuw op het doel en maakt ook een samenvoegdoorvoering.

Notitie

Deze functie is beschikbaar voor Azure DevOps Server 2020 en latere versies.

Een samenvoegstrategie afdwingen

Behoud een consistente vertakkingsgeschiedenis door een samenvoegstrategie af te dwingen wanneer een pull-aanvraag is voltooid. Selecteer Een samenvoegstrategie afdwingen en kies een optie om te vereisen dat pull-aanvragen worden samengevoegd met die strategie.

Vereisten voor samenvoegen instellen

  • Geen snelle samenvoegbewerking . Met deze optie wordt de doorvoergeschiedenis van de bronvertakking samengevoegd wanneer de pull-aanvraag wordt gesloten en er een samenvoegdoorvoering wordt gemaakt in de doelvertakking.
  • Squash samenvoegen : voltooi alle pull-aanvragen met een squashsamenvoeging, waardoor één doorvoer in de doelvertakking wordt gemaakt met de wijzigingen van de bronvertakking. Meer informatie over het samenvoegen van squashs en hoe dit van invloed is op uw vertakkingsgeschiedenis.

Buildvalidatie

U kunt een beleid instellen waarvoor pull-aanvraagwijzigingen moeten worden gemaakt voordat de pull-aanvraag kan worden voltooid. Bouwbeleid vermindert onderbrekingen en zorgt ervoor dat uw testresultaten worden doorgegeven. Het bouwen van beleidsregels helpt zelfs als u continue integratie (CI) op uw ontwikkelvertakkingen gebruikt om problemen vroeg te ondervangen.

Met een buildvalidatiebeleid wordt een nieuwe build in de wachtrij geplaatst wanneer er een nieuwe pull-aanvraag wordt gemaakt of wijzigingen worden gepusht naar een bestaande pull-aanvraag die is gericht op de vertakking. Het buildbeleid evalueert de buildresultaten om te bepalen of de pull-aanvraag kan worden voltooid.

Belangrijk

Voordat u een buildvalidatiebeleid opgeeft, moet u een build-pijplijn hebben. Zie Een build-pijplijn maken als u geen pijplijn hebt. Kies het type build dat overeenkomt met uw projecttype.

Een buildvalidatiebeleid toevoegen

  1. Selecteer de + knop naast buildvalidatie.

    Schermopname van de knop Toevoegen naast buildvalidatie.

  2. Vul het formulier Build-beleid instellen in:

    Beleidsinstellingen bouwen

    • Selecteer de build-pijplijn.

    • U kunt desgewenst een padfilter instellen. Meer informatie over padfilters in vertakkingsbeleid.

    • Selecteer onder Trigger Automatisch (wanneer de bronbranch wordt bijgewerkt) of Handmatig.

    • Selecteer Vereist of Optioneel onder Beleidsvereiste. Als u Vereist kiest, moeten builds worden voltooid om PULL's te voltooien. Kies Optioneel als u een melding wilt opgeven van de buildfout, maar toch toestaan dat PULL's worden voltooid.

    • Stel een verlooptijd van een build in om ervoor te zorgen dat wijzigingen in uw beveiligde vertakking niet worden onderbroken voor geopende PULL's.

      • Onmiddellijk wanneer <de naam> van de vertakking wordt bijgewerkt: met deze optie wordt de status van het buildbeleid voor pull-aanvraag ingesteld op mislukt wanneer de vertakking wordt bijgewerkt en wordt een build opnieuw in de wachtrij weergegeven. Deze instelling zorgt ervoor dat de pull-aanvraag wordt aangepast, zelfs als de beveiligde vertakking wordt gewijzigd.

        Deze optie is het beste voor teams waarvan de belangrijke vertakkingen weinig wijzigingen hebben. Teams die in drukke ontwikkelvertakkingen werken, kunnen het verstorend vinden om te wachten op een build telkens wanneer de vertakking wordt bijgewerkt.

      • Na <n> uur als <de naam> van de vertakking is bijgewerkt: deze optie verloopt de huidige beleidsstatus wanneer de beveiligde vertakking wordt bijgewerkt als de doorgegeven build ouder is dan de drempelwaarde die u invoert. Deze optie is een compromis tussen altijd of nooit een build vereisen wanneer de beveiligde vertakking wordt bijgewerkt. Deze keuze vermindert het aantal builds wanneer uw beveiligde vertakking regelmatig updates heeft.

      • Nooit: Updates voor de beveiligde vertakking wijzigen de beleidsstatus niet. Deze waarde vermindert het aantal builds, maar kan problemen veroorzaken bij het voltooien van PULL's die onlangs niet zijn bijgewerkt.

    • Voer een optionele weergavenaam in voor dit buildbeleid. Deze naam identificeert het beleid op de pagina Vertakkingsbeleid . Als u geen weergavenaam opgeeft, gebruikt het beleid de naam van de build-pijplijn.

  3. Selecteer Opslaan.

Wanneer de eigenaar van de pull-aanvraag wijzigingen pusht die zijn gemaakt, wordt de beleidsstatus bijgewerkt.

Als u de naam van de vertakking onmiddellijk <hebt bijgewerkt of na <n> uur als <de naam van de vertakking> is bijgewerkt, wordt de beleidsstatus bijgewerkt wanneer de beveiligde vertakking wordt bijgewerkt, als de vorige build niet meer geldig> is.

Notitie

Deze functie is beschikbaar voor Azure DevOps Server 2020 en latere versies.

Stel een beleid in waarvoor wijzigingen in een pull-aanvraag nodig zijn om te worden gebouwd met de beveiligde vertakking voordat de pull-aanvraag kan worden voltooid. Bouwbeleid vermindert onderbrekingen en zorgt ervoor dat uw testresultaten worden doorgegeven. Het bouwen van beleidsregels helpt zelfs als u continue integratie (CI) op uw ontwikkelvertakkingen gebruikt om problemen vroeg te ondervangen.

Als een buildvalidatiebeleid is ingeschakeld, wordt een nieuwe build in de wachtrij geplaatst wanneer er een nieuwe pull-aanvraag wordt gemaakt of als wijzigingen worden gepusht naar een bestaande pull-aanvraag die gericht is op de vertakking. Het buildbeleid evalueert vervolgens de resultaten van de build om te bepalen of de pull-aanvraag kan worden voltooid.

Belangrijk

Voordat u een buildvalidatiebeleid opgeeft, moet u een builddefinitie hebben. Als u er nog geen hebt, raadpleegt u Een builddefinitie maken en kiest u het type build dat overeenkomt met uw projecttype.

Buildbeleid toevoegen

Kies Buildbeleid toevoegen en configureer uw opties in Build-beleid toevoegen.

Beleidsinstellingen bouwen

  1. Selecteer de builddefinitie.

  2. Kies het type trigger. Selecteer Automatisch (wanneer de bronbranch wordt bijgewerkt) of Handmatig.

  3. Selecteer de beleidsvereiste. Als u Vereist kiest, moeten builds worden voltooid om pull-aanvragen te voltooien. Kies Optioneel om een melding van de buildfout op te geven, maar laat pull-aanvragen nog steeds voltooien.

  4. Stel een verlooptijd van de build in om ervoor te zorgen dat wijzigingen in uw beveiligde vertakking niet worden onderbroken voor openstaande pull-aanvragen.

    • Onmiddellijk wanneer branch name wordt bijgewerkt: met deze optie stelt u de status van het buildbeleid in een pull-aanvraag in op mislukt wanneer de beveiligde vertakking wordt bijgewerkt. Een build opnieuw weergeven om de buildstatus te vernieuwen. Deze instelling zorgt ervoor dat de wijzigingen in pull-aanvragen worden gebouwd, zelfs als de beveiligde vertakking verandert. Deze optie is het beste voor teams met belangrijke vertakkingen met een lager volume aan wijzigingen. Teams die in drukke ontwikkelvertakkingen werken, kunnen het verstorend vinden om te wachten tot een build is voltooid wanneer de beveiligde vertakking wordt bijgewerkt.
    • Na n uren als branch name deze optie is bijgewerkt: deze optie verloopt de huidige beleidsstatus wanneer de beveiligde vertakking wordt bijgewerkt als de doorgegeven build ouder is dan de drempelwaarde die is ingevoerd. Deze optie is een compromis tussen het altijd vereisen van een build wanneer de beveiligde vertakking wordt bijgewerkt en er nooit een nodig is. Deze keuze is uitstekend voor het verminderen van het aantal builds wanneer uw beveiligde vertakking regelmatig updates heeft.
    • Nooit: Updates voor de beveiligde vertakking wijzigen de beleidsstatus niet. Deze waarde vermindert het aantal builds voor uw vertakking. Dit kan problemen veroorzaken bij het sluiten van pull-aanvragen die onlangs niet zijn bijgewerkt.

  5. Voer een optionele weergavenaam in voor dit buildbeleid. Deze naam identificeert het beleid op de pagina Vertakkingsbeleid . Als u geen weergavenaam opgeeft, gebruikt het beleid de naam van de builddefinitie.

  6. Selecteer Opslaan.

Wanneer de eigenaar wijzigingen pusht die zijn gemaakt, wordt de beleidsstatus bijgewerkt. Als u onmiddellijk branch name een update hebt of na n uren als branch name het buildbeleid is bijgewerkt, wordt de beleidsstatus bijgewerkt wanneer de beveiligde vertakking wordt bijgewerkt als de meest recente build niet meer geldig is.

Statuscontroles

Externe services kunnen de PR-status-API gebruiken om gedetailleerde status te posten op uw PULL's. Met het vertakkingsbeleid voor aanvullende services kunnen deze services van derden deelnemen aan de pull-werkstroom en beleidsvereisten vaststellen.

Externe services vereisen om goed te keuren

Zie Een vertakkingsbeleid configureren voor een externe service voor instructies voor het configureren van dit beleid.

Goedkeuring van externe services vereisen

Externe services kunnen de PR-status-API gebruiken om gedetailleerde status te posten op uw PULL's. Het vertakkingsbeleid voor aanvullende services biedt de mogelijkheid voor deze services van derden om deel te nemen aan de pull-werkstroom en beleidsvereisten vast te stellen.

Externe services vereisen om goed te keuren

Zie Een vertakkingsbeleid configureren voor een externe service voor instructies voor het configureren van dit beleid.

Coderevisoren automatisch opnemen

U kunt automatisch revisoren toevoegen aan pull-aanvragen die bestanden wijzigen in specifieke mappen en bestanden, of aan alle pull-aanvragen in een opslagplaats.

  1. Selecteer de + knop naast Automatisch opgenomen revisoren.

    Schermopname van Vereiste revisoren toevoegen.

  2. Vul het scherm Nieuw revisorbeleid toevoegen in.

    Schermopname van het scherm Nieuw revisorbeleid toevoegen.

    • Voeg personen en groepen toe aan revisoren.

    • Selecteer Optioneel als u revisoren automatisch wilt toevoegen, maar hun goedkeuring niet nodig hebt om de pull-aanvraag te voltooien.

      Of selecteer Vereist als pull-aanvragen pas kunnen worden voltooid:

      • Elke persoon die als revisor wordt toegevoegd, keurt de wijzigingen goed.
      • Ten minste één persoon in elke groep die als revisor is toegevoegd, keurt de wijzigingen goed.
      • Als er slechts één groep is vereist, wordt het minimale aantal leden dat u opgeeft de wijzigingen goedkeurd.

    • Geef de bestanden en mappen op waarvoor de automatisch opgenomen revisoren zijn vereist. Laat dit veld leeg om de revisoren voor alle pull-aanvragen in de vertakking te vereisen.

    • Selecteer Toestaan dat aanvragers hun eigen wijzigingen goedkeuren als eigenaren van pull-aanvragen kunnen stemmen om hun eigen pull-aanvragen goed te keuren om aan dit beleid te voldoen.

    • U kunt een activiteitsfeedbericht opgeven dat wordt weergegeven in de pull-aanvraag.

  3. Selecteer Opslaan.

Notitie

Deze functie is beschikbaar voor Azure DevOps Server 2020 en latere versies.

Selecteer revisoren voor specifieke mappen en bestanden in uw opslagplaats.

Voer het pad en de vereiste revisoren in

Deze revisoren worden automatisch toegevoegd aan pull-aanvragen die bestanden op deze paden wijzigen. U kunt ook een activiteitsfeedbericht opgeven.

Automatische revisoren toevoegen

Als u Vereist selecteert, kan de pull-aanvraag pas worden voltooid als:

  • Elke gebruiker die als revisor voor het pad is toegevoegd, keurt de wijzigingen goed.
  • Ten minste één persoon in elke groep die aan het pad is toegevoegd, keurt de wijzigingen goed.
  • Het aantal revisoren dat is opgegeven voor elke groep die aan het pad is toegevoegd, keurt de wijzigingen goed.

Vereiste revisoren worden automatisch toegevoegd

Selecteer Optioneel als u revisoren automatisch wilt toevoegen, maar hun goedkeuring niet nodig hebt om de pull-aanvraag te voltooien.

U kunt aanvragers selecteren die hun eigen wijzigingen kunnen goedkeuren.

Wanneer alle vereiste revisoren de code goedkeuren, kunt u de pull-aanvraag voltooien.

Status van pull-aanvraag geeft aan dat revisoren zijn goedgekeurd

Vertakkingsbeleid overslaan

In sommige gevallen moet u mogelijk beleidsvereisten overslaan. Met bypass-machtigingen kunt u wijzigingen rechtstreeks naar een vertakking pushen of pull-aanvragen voltooien die niet voldoen aan vertakkingsbeleid. U kunt bypassmachtigingen verlenen aan een gebruiker of groep. U kunt machtigingen voor het overslaan van een hele project, een opslagplaats of één vertakking instellen.

Met twee machtigingen kunnen gebruikers vertakkingsbeleid op verschillende manieren omzeilen:

  • Overslaan van beleid bij het voltooien van pull-aanvragen is alleen van toepassing op voltooiing van pull-aanvragen . Gebruikers met deze machtiging kunnen pull-aanvragen voltooien, zelfs als de pull-aanvragen niet voldoen aan beleid.

  • Sla beleidsregels over wanneer pushen van toepassing is op pushes vanuit lokale opslagplaatsen en bewerkingen die op internet zijn aangebracht. Gebruikers met deze machtiging kunnen wijzigingen rechtstreeks naar beveiligde vertakkingen pushen zonder aan beleidsvereisten te voldoen.

Schermopname van het negeren van beleidsafdwingingsmachtigingen.

Zie Git-machtigingen voor meer informatie over het beheren van deze machtigingen.

In TFS 2015 tot en met TFS 2018 Update 2 staat de machtiging Uitsluiten van beleidsafdwinging gebruikers met deze machtiging toe om de volgende acties uit te voeren:

  • Wanneer u een pull-aanvraag voltooit, meldt u zich aan om beleidsregels te overschrijven en een pull-aanvraag te voltooien, zelfs als niet aan de huidige set vertakkingsbeleidsregels wordt voldaan.
  • Rechtstreeks naar een vertakking pushen, zelfs als er een vertakkingsbeleid is ingesteld. Wanneer een gebruiker met deze machtiging een push uitvoert die vertakkingsbeleid overschrijft, wordt het vertakkingsbeleid automatisch overgeslagen zonder aanmeldingsstap of waarschuwing.

Belangrijk

Wees voorzichtig bij het verlenen van de mogelijkheid om beleidsregels te omzeilen, met name op de opslagplaats- en projectniveaus. Beleidsregels vormen een hoeksteen van veilig en compatibel broncodebeheer.

Padfilters

Verschillende vertakkingsbeleidsregels bieden padfilters. Als een padfilter is ingesteld, is het beleid alleen van toepassing op bestanden die overeenkomen met het padfilter. Als u dit veld leeg laat, betekent dit dat het beleid van toepassing is op alle bestanden in de vertakking.

U kunt absolute paden opgeven (pad moet beginnen met / of een jokerteken) en jokertekens. Voorbeelden:

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

U kunt meerdere paden opgeven met behulp van ; een scheidingsteken. Voorbeeld:

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

Paden met voorvoegsel worden ! uitgesloten als ze anders zouden worden opgenomen. Voorbeeld:

  • /WebApp/*;!/WebApp/Tests/* bevat alle bestanden in /WebApp behalve bestanden in /WebApp/Tests
  • !/WebApp/Tests/* geeft geen bestanden, omdat niets eerst is opgenomen

De volgorde van filters is aanzienlijk. Filters worden van links naar rechts toegepast.

Vragen en antwoorden

Kan ik wijzigingen rechtstreeks naar vertakkingen met vertakkingsbeleid pushen?

U kunt wijzigingen niet rechtstreeks pushen naar vertakkingen met vereist vertakkingsbeleid, tenzij u gemachtigd bent om vertakkingsbeleid over te slaan. Wijzigingen in deze vertakkingen kunnen alleen worden aangebracht via pull-aanvragen. U kunt wijzigingen rechtstreeks naar vertakkingen met optionele vertakkingsbeleid pushen als ze geen vereist vertakkingsbeleid hebben.

Wat is automatisch aanvullen?

Pull-aanvragen naar vertakkingen waarvoor vertakkingsbeleid is geconfigureerd, hebben de knop Automatisch aanvullen instellen. Selecteer deze optie om de pull-aanvraag automatisch te voltooien zodra deze voldoet aan alle beleidsregels. Automatisch aanvullen is handig wanneer u geen problemen met uw wijzigingen verwacht.

Wanneer worden voorwaarden voor vertakkingsbeleid gecontroleerd?

Vertakkingsbeleid wordt opnieuw geëvalueerd op de server wanneer eigenaren van pull-aanvragen wijzigingen pushen en wanneer revisoren stemmen. Als een beleid een build activeert, wordt de buildstatus ingesteld op wachten totdat de build is voltooid.

Kan ik XAML-builddefinities gebruiken in vertakkingsbeleid?

Nee, u kunt geen XAML-builddefinities gebruiken in vertakkingsbeleid.

Welke jokertekens kan ik gebruiken voor vereiste coderevisoren?

Enkele sterretjes * komen overeen met een willekeurig aantal tekens, inclusief zowel slashes / als back-slashes \. Vraagtekens ? komen overeen met één teken.

Voorbeelden:

  • *.sql komt overeen met alle bestanden met de extensie .sql .
  • /ConsoleApplication/*komt overeen met alle bestanden onder de map ConsoleApplication.
  • /.gitattributes komt overeen met het .gitattributes-bestand in de hoofdmap van de opslagplaats.
  • */.gitignore komt overeen met elk .gitignore-bestand in de opslagplaats.

Zijn de vereiste coderevisorpaden hoofdlettergevoelig?

Nee, vertakkingsbeleid is niet hoofdlettergevoelig.

Hoe kan ik meerdere gebruikers configureren als vereiste revisoren, maar slechts één van hen moet goedkeuren?

U kunt de gebruikers toevoegen aan een groep en vervolgens de groep toevoegen als revisor. Elk lid van de groep kan vervolgens goedkeuren om te voldoen aan de beleidsvereiste.

Ik heb beleidsmachtigingen overslaan. Waarom zie ik nog steeds beleidsfouten in de status van de pull-aanvraag?

Geconfigureerde beleidsregels worden altijd geëvalueerd voor wijzigingen in pull-aanvragen. Voor gebruikers die beleidsmachtigingen omzeilen, is de gerapporteerde beleidsstatus alleen advies. Als de gebruiker met bypassmachtigingen goedkeurt, blokkeert de foutstatus de voltooiing van pull-aanvragen niet.

Waarom kan ik mijn eigen pull-aanvragen niet voltooien wanneer 'Aanvragers toestaan hun eigen wijzigingen goed te keuren'?

Zowel het minimum aantal revisorenbeleid als het beleid voor automatisch opgenomen revisoren vereisen, hebben opties om aanvragers toe te staan hun eigen wijzigingen goed te keuren. In elk beleid is de instelling alleen van toepassing op dat beleid. De instelling heeft geen invloed op het andere beleid.

Uw pull-aanvraag heeft bijvoorbeeld de volgende beleidsregels ingesteld:

  • Voor een minimum aantal revisoren is ten minste één revisor vereist.
  • Voor automatisch opgenomen revisoren is vereist dat u of een team waarin u zich bevindt als revisor.
  • Revisoren die automatisch zijn opgenomen, hebben toestaan dat aanvragers hun eigen wijzigingen goedkeuren.
  • Vereisen dat een minimum aantal revisoren niet toestaat dat aanvragers hun eigen wijzigingen kunnen goedkeuren.

In dit geval voldoet uw goedkeuring aan automatisch opgenomen revisoren, maar niet aan een minimum aantal revisoren, zodat u de pull-aanvraag niet kunt voltooien.

Er kunnen ook andere beleidsregels zijn, zoals verbieden dat de meest recente pusher hun eigen wijzigingen goedkeurt, waardoor u uw eigen wijzigingen niet kunt goedkeuren, zelfs als aanvragers toestaan om hun eigen wijzigingen goed te keuren, is ingesteld.

Wat gebeurt er wanneer het pad in padfilters niet begint met / of met jokertekens?

Het pad in padfilters die niet beginnen met / of met een jokerteken, heeft geen effect en het padfilter evalueert alsof dat pad niet is opgegeven. Dat komt doordat een dergelijk pad niet overeenkomt met het / absolute bestandspad.