Branchbeleid instellen en beheren

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

Gebruik branchbeleid om belangrijke branches te beveiligen door pull requests, reviewers, builds en andere controles te vereisen voordat wijzigingen worden samengevoegd. In dit artikel wordt beschreven hoe u vertakkingsbeleid configureert en beheert in de Azure DevOps-webportal en Azure DevOps CLI. Zie Over branches en branchbeleid voor een overzicht van beschikbaar branchbeleid en richtlijnen voor branches.

Zie Veilige opslagplaatsen en pull-aanvragen voor een uitgebreide beveiligingshandleiding voor vertakkingsbeleid, toegangsbeheer voor opslagplaatsen, ondertekening doorvoeren en praktijkscenario's.

U kunt een branch waarvoor vereist beleid is geconfigureerd niet verwijderen, en alle wijzigingen moeten via pull requests (PR's) verlopen.

Aanbeveling

U kunt AI gebruiken om bij deze taak te helpen verderop in dit artikel, of zie AI-assistentie inschakelen met Azure DevOps MCP Server om te beginnen.

Vereisten

Requirement Details
Permissions Wees lid van de beveiligingsgroep Project Administrators of heb machtigingen voor beleid bewerken op opslagplaatsniveau. Zie Machtigingen voor Git-opslagplaatsen instellen voor meer informatie.
Azure DevOps CLI instellen (optioneel) Als u Azure DevOps CLI az repos policy commands wilt gebruiken, voltooit u Aan de slag met Azure DevOps CLI.
Repository-doelselectie voor CLI (optioneel) Voordat u beleidsregels in CLI maakt of bijwerkt, identificeert u de opslagplaats-id door deze uit te voeren az repos list. Om herhaling van --org en --project te voorkomen, stelt u standaardwaarden in met az devops configure --defaults.
Beleidsafhankelijkheden Voordat u buildvalidatie configureert, moet u een build-pijplijn gereed hebben. Voordat u statuscontroles configureert, moet u ervoor zorgen dat de externe service of ingebouwde integratie al de status van de pull-aanvraag kan posten.
Configuratie van AI-hulp (optioneel) Als u AI-hulp wilt gebruiken met Azure DevOps MCP Server, gebruikt u Azure DevOps Services, schakelt u de agentmodus in uw AI-assistent in en installeert u Node.js 20.0+. Zie Ai-hulp inschakelen met Azure DevOps MCP-server voor meer informatie.
Requirement Details
Permissions Wees lid van de beveiligingsgroep Project Administrators of heb machtigingen voor beleid bewerken op opslagplaatsniveau. Zie Machtigingen voor Git-opslagplaatsen instellen voor meer informatie.

Instellingen voor branchbeleid openen

Ga als volgt te werk om de instellingen voor vertakkingsbeleid in het webportaal te openen:

  1. Selecteer Repositories>Branches.
  2. Zoek het filiaal dat u wilt beheren.
  3. Selecteer het pictogram Meer opties naast de branch en selecteer vervolgens Beleid voor branch.

Schermopname van het menu-item Branches.

U kunt instellingen voor vertakkingsbeleid ook openen via Projectinstellingen>Opslagplaats>Beleid>Vertakkingsbeleid><Vertakkingsnaam>.

Afdelingen met beleid tonen een beleidspictogram. Selecteer het pictogram om direct naar de beleidsinstellingen van de branch te gaan.

U kunt door de lijst bladeren of zoeken naar het filiaal in het vak Filiaalnaam zoeken.

Schermopname die toont hoe je het vertakkingsbeleid opent vanuit het contextmenu.

Stel beleidsregels in op de instellingenpagina van de vestiging. Gebruik de volgende secties om elk beleid in te schakelen of een bestaand beleid bij te werken.

Een minimumbeleid voor revisoren instellen

Goedkeuring van een minimum aantal revisoren vereisen voordat een pull-aanvraag kan worden voltooid.

Om het beleid in te stellen, stelt u onder VertakkingsbeleidEen minimum aantal revisoren vereisen in op Aan. Voer het vereiste aantal revisoren in en selecteer een van de volgende opties:

Schermopname die het inschakelen van het beleid 'Codebeoordelingen vereisen' toont.

  • Selecteer Aanvragers toestaan om hun eigen wijzigingen goed te keuren om de maker van een pull request toe te staan te stemmen op de goedkeuring ervan. Anders kan de maker nog steeds op de PR Approve stemmen, maar die stem telt niet mee voor het minimumaantal reviewers.

  • Selecteer het verbieden van de meest recente pusher om hun eigen wijzigingen goed te keuren om de scheiding van taken af te dwingen. Standaard kan iedereen met pushmachtigingen voor de bronbranch zowel commits toevoegen als stemmen op de goedkeuring van de pull request. 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 goedkeuring geven.

  • 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 moet een andere goedkeuring voor de laatste iteratie worden uitgevoerd 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 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 wijzigt.
    • Selecteer Alle stemmen van de coderevisor opnieuw instellen om alle revisorstemmen te verwijderen wanneer de bronbranch verandert, inclusief stemmen om goed te keuren, te weigeren of te wachten.

Als aan alle andere beleidsregels wordt voldaan, kan de maker de pull request voltooien wanneer het vereiste aantal beoordelaars deze goedkeurt.

Gekoppelde werkitems vereisen

Voor het beheer en bijhouden van werkitems kunt u verbindingen tussen PR'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 VertakkingsbeleidControleren op gekoppelde werkitems in op Aan. Voor deze instelling moeten werkonderdelen worden gekoppeld aan een PR voordat de PR kan worden samengevoegd. 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.

Vereis dat opmerkingen worden opgelost

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

Stel Oplossen van opmerkingen controleren in op Aan om voor uw branch een beleid voor het oplossen van opmerkingen in te stellen. Selecteer vervolgens of u het beleid vereist of optioneel wilt maken.

Schermopname van Controleren op resolutie van opmerkingen.

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

Samenvoegtypen beperken

Azure-opslagplaatsen ondersteunt verschillende samenvoegstrategieën en standaard zijn ze allemaal toegestaan. Als u een consistente branchgeschiedenis wilt behouden, dwing dan een samenvoegingsstrategie af bij het voltooien van pull requests.

Zet Typen samenvoegingen beperken op Aan om te beperken welke typen samenvoegingen zijn toegestaan in uw repository.

Schermopname van Limiteer samenvoegingstypen.

  • Met een eenvoudige samenvoeging (geen fast-forward) wordt een merge-commit gemaakt in de doelbranch waarvan de ouders de doel- en bronbranch zijn.
  • Squash merge creëert een lineaire geschiedenis met één commit in de doelbranch, waarbij de wijzigingen uit de bronbranch worden opgenomen. Meer informatie over squash-merge en hoe dit invloed heeft op de geschiedenis van takken.
  • Rebase en fast-forward maakt een lineaire geschiedenis door bron commits opnieuw toe te passen op de doelbranch zonder merge commit.
  • Rebase met merge commit plaatst de bronscommits opnieuw op het doel en maakt ook een mergecommit.

Buildvalidatie instellen

Stel een beleid in waarbij wijzigingen in de pull-aanvraag eerst succesvol moeten worden gebouwd voordat de pull-aanvraag kan worden voltooid. Beleid voor het bouwen vermindert onderbrekingen en zorgt ervoor dat uw testresultaten succesvol blijven. Het bouwen van beleidsregels helpt zelfs als u continue integratie (CI) op uw ontwikkelvertakkingen gebruikt om problemen vroeg te ondervangen.

Wanneer u de beleidstrigger instelt op Automatisch, wordt er met een buildvalidatiebeleid een nieuwe build in de wachtrij geplaatst wanneer u een nieuwe PR maakt of wijzigingen doorvoert in een bestaande PR die gericht is op de branch. Als u de beleidstrigger instelt op Handmatig, moeten gebruikers de build zelf in de wachtrij plaatsen. In beide gevallen beoordeelt het beleid de buildresultaten om te bepalen of de PR kan worden afgerond.

Belangrijk

Voordat u een beleid voor buildvalidatie instelt, maakt u een build-pipeline. Als u geen pijplijn hebt, zie Een build-pijplijn maken. Kies het type build dat overeenkomt met uw projecttype.

Een buildvalidatiebeleid toevoegen

  1. Selecteer de + button naast buildvalidatie.

    Schermopname van de knop Toevoegen naast buildvalidatie.

  2. Vul het formulier voor het instellen van het bouwbeleid in:

    Schermopname van de buildbeleidinstellingen.

    • Selecteer de build-pijplijn.

  • U kunt desgewenst een padfilter instellen. Ontdek meer over padfilters in branch-beleid.

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

  • Selecteer Vereist of Optioneel onder Beleidsvereiste. Als u Vereist kiest, moeten builds succesvol worden voltooid om PR's af te ronden. Kies Optioneel om een melding van de buildfout te geven, maar toch toe te staan dat PR's worden voltooid.

  • Stel een vervaldatum van een build in om ervoor te zorgen dat updates aan uw beveiligde vertakking geen problemen veroorzaken voor openstaande PR'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 wijzigingen in de pull request succesvol worden gebouwd, 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 ontwikkeltakken werken, vinden het storend om te moeten wachten op een build bij elke update van de tak.

    • 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 beschermde branch 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 afronden van pull requests die onlangs niet zijn bijgewerkt.

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

  1. Selecteer Opslaan.

Wanneer de eigenaar van de pull request wijzigingen pusht die succesvol worden gebouwd, wordt de beleidsstatus bijgewerkt.

Als u een bouwbeleid heeft van Onmiddellijk wanneer <de vertakkingsnaam> is bijgewerkt of Na <n> uur als <de vertakkingsnaam> is bijgewerkt, wordt de beleidsstatus bijgewerkt wanneer de beveiligde vertakking wordt bijgewerkt, als de vorige build niet meer geldig is.

Statuscontroles verplicht stellen

Externe diensten kunnen de PR Status API gebruiken om gedetailleerde status te posten op uw PR's. Het branches beleid voor aanvullende services stelt deze externe services in staat om deel te nemen aan de PR-werkstroom en beleidsvereisten vast te stellen.

Schermopname van Externe services moeten goedkeuren.

Een statuscontrolebeleid configureren:

  1. Zorg ervoor dat de service de status van de pull-aanvraag kan posten naar Azure-opslagplaatsen.
  2. Selecteer in Branch-beleid, onder Statuscontroles, de optie +.
  3. Selecteer in De status die u wilt controleren de geplaatste controle in de lijst. Als de service de status nog niet heeft gepost, typt u de genre/name waarde rechtstreeks.
  4. Stel de beleidsvereiste in op Vereist of Optioneel.
  5. Configureer eventueel geautoriseerde identiteit, voorwaarden opnieuw instellen, toepasselijkheid van beleid en padfilter.
    • Gebruik Standaard Toepassen als het beleid van toepassing moet zijn zodra de pull-aanvraag is gemaakt.
    • Gebruik Voorwaardelijk als het beleid pas van toepassing moet zijn nadat de eerste status is geplaatst.
  6. Maak een pull request voor de branch of werk deze bij, en controleer of het beleid wordt weergegeven in de sectie Policies van de pull request.

Zie Beschikbare statuscontroles voor pull requests voor de ingebouwde controles van Azure DevOps Services en hun genre/name id’s. Zie Een branchbeleid configureren voor een externe service voor een volledige stapsgewijze uitleg van het instellen van een externe service.

Als een nieuwe integratie nog niet in de vervolgkeuzelijst wordt weergegeven, publiceert u één keer een status vanuit de service en voegt u daarna het beleid toe, of typt u de waarde genre/name rechtstreeks.

Revisoren 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 die 'Vereiste beoordelaars toevoegen' weergeeft.

  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 niet kunnen worden afgerond voordat:

      • 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, keurt het minimale aantal leden dat u opgeeft de wijzigingen goed.

    • Geef de bestanden en mappen op waarvoor automatisch opgenomen revisoren vereist zijn. Laat dit veld leeg om de revisoren voor alle pull requests in de branch vereist te stellen.

    • 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.

Toestaan dat beleid wordt omzeild wanneer dat nodig is

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 en deze machtigingen instellen voor een volledig project, een opslagplaats of één vertakking.

Met twee machtigingen kunnen gebruikers vertakkingsbeleid op verschillende manieren omzeilen:

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

  • Beleidsregels overslaan bij het pushen is van toepassing op pushes vanuit lokale opslagplaatsen en bewerkingen die op het web zijn aangebracht. Gebruikers met deze machtiging kunnen wijzigingen rechtstreeks naar beveiligde vertakkingen pushen zonder aan beleidsvereisten te voldoen.

Schermopname met machtigingen voor het omzeilen van beleidshandhaving.

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

Belangrijk

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

Padfilters gebruiken met vertakkingsbeleid

Verschillende beleidsregels voor branches ondersteunen padfilters. Als u een padfilter instelt, is het beleid alleen van toepassing op bestanden die overeenkomen met het filter. Laat dit veld leeg om het beleid toe te passen op alle bestanden in de branch.

U kunt absolute paden opgeven (het 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

Als u paden met voorvoegsel !gebruikt, sluit u deze uit als ze anders zijn opgenomen. Voorbeeld:

  • /WebApp/*;!/WebApp/Tests/* bevat alle bestanden in /WebApp behalve bestanden in /WebApp/Tests
  • !/WebApp/Tests/* specificeert geen bestanden, aangezien er eerst niets is inbegrepen

De volgorde van filters is aanzienlijk. Filters van links naar rechts toepassen.

Problemen met beleid voor branches oplossen

Kan ik wijzigingen rechtstreeks pushen naar branches die vertakkingsbeleid hebben?

U kunt geen wijzigingen pushen naar branches met vereist branchebeleid, tenzij u toestemming hebt om het branchebeleid te omzeilen. U kunt alleen wijzigingen aanbrengen in deze branches met pull requests. U kunt wijzigingen direct pushen naar branches met optioneel vertakkingsbeleid, als ze geen verplicht vertakkingsbeleid hebben.

Wat is automatisch aanvullen?

Branches waarvoor branchbeleid is geconfigureerd voor pullaanvragen, hebben de knop Automatisch voltooien instellen. Selecteer deze optie om een pull-aanvraag in te stellen voor automatisch aanvullen zodra deze voldoet aan alle beleidsregels. Automatisch aanvullen is handig wanneer u geen problemen met uw wijzigingen verwacht.

Wanneer worden voorwaarden voor branchebeleid gecontroleerd?

De server evalueert vertakkingsbeleid opnieuw 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 backslashes \. Vraagtekens ? komen overeen met een enkel willekeurig 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, branchbeleid 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 kan beleidsmachtigingen omzeilen. Waarom zie ik nog steeds beleidsfouten in de status van de pull-aanvraag?

Het systeem evalueert altijd geconfigureerde beleidsregels voor wijzigingen in pull-aanvragen. Voor gebruikers die beleidsmachtigingen hebben omzeild, 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 ik toestaan dat aanvragers hun eigen wijzigingen goedkeuren?

Zowel het beleid voor het vereiste minimum aantal revisoren als het beleid voor automatisch opgenomen revisoren hebben opties om aanvragers toe te staan hun eigen wijzigingen goed te keuren. In elke polis is de instelling alleen van toepassing op die polis. De instelling beïnvloedt het andere beleid niet.

Uw pull-aanvraag heeft bijvoorbeeld de volgende beleidsregels ingesteld:

  • Voor een minimum aantal revisoren is ten minste één revisor vereist.
  • Automatisch opgenomen reviewers vereisen dat u of een team waarin u zit als reviewer optreedt.
  • Revisoren die automatisch zijn opgenomen, hebben toestaan dat aanvragers hun eigen wijzigingen goedkeuren.
  • Het vereisen van een minimum aantal beoordelaars heeft niet de optie toestaan dat aanvragers hun eigen wijzigingen goedkeuren ingeschakeld.

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

Andere beleidsregels kunnen voorkomen dat u uw eigen wijzigingen goedkeurt, zelfs als aanvragers toestaan hun eigen wijzigingen goed te keuren , is ingesteld. Verbied bijvoorbeeld dat de meest recente bijdrager zijn of haar eigen wijzigingen goedkeurt.

Wat gebeurt er wanneer een padfilter niet begint met / of een jokerteken?

Een pad in padfilters dat niet begint met / of een jokerteken, heeft geen effect. Het padfilter evalueert alsof dat pad niet is opgegeven. Een dergelijk pad kan niet overeenkomen met het / absolute bestandspad dat begint met.

AI gebruiken om branchbeleid te configureren en te beheren

Als u de Azure DevOps MCP-server configureert, kunt u natuurlijke taal gebruiken om opslagplaatsen, vertakkingen, pull-aanvragen en buildcontext te verzamelen voordat u vertakkingsbeleid bijwerkt in Azure DevOps Services.

De Azure DevOps MCP-server vereist Azure DevOps Services, agentmodus in uw AI-assistent en Node.js 20.0+. In de huidige MCP-documentatie worden geen lees- of schrijfacties voor direct branch-beleid beschreven. Gebruik daarom de Azure DevOps webportal of Azure DevOps CLI om beleid te maken en bij te werken.

Task Voorbeeldprompt
Vertakkingen in een repository lijst tonen List the branches in repo <Contoso.Web> in project <Contoso>
Pull-aanvragen controleren voordat het beleid wordt aangescherpt What pull requests require my review in project <Contoso>?
Een pull-aanvraag en gekoppelde werkitems inspecteren Get details for pull request <67> and its linked work items in project <Contoso>
Controleer de buildstatus voordat u buildvalidatie verplicht stelt Get the latest build status for pipeline <Contoso-CI> in project <Contoso>

Opmerking

Als u Visual Studio Code gebruikt, is de agentmodus vooral handig voor het verzamelen van de projectcontext die u nodig hebt voordat u vertakkingsbeleid bijwerkt.

Verwante onderwerpen

  • Last updated on