Hoe pull-aanvragen te verzenden

Als u wijzigingen wilt aanbrengen in inhoud, dient u een pull-aanvraag (PR) in vanuit uw fork. Een pull-aanvraag moet worden gecontroleerd voordat deze kan worden samengevoegd. Bekijk voor de beste resultaten de redactionele controlelijst voordat u uw pull-aanvraag indient.

Git-vertakkingen gebruiken

De standaardbranch voor PowerShell-Docs is de main branch. Wijzigingen die in werkbranches worden aangebracht, worden samengevoegd in de main tak voordat ze worden gepubliceerd. De main vertakking wordt elke weekdag om 15:00 uur samengevoegd in de live vertakking (Pacific Time). De live vertakking bevat de inhoud die wordt gepubliceerd naar learn.microsoft.com.

Voordat u wijzigingen start, maakt u een werkbranch in uw lokale kopie van de PowerShell-Docs opslagplaats. Wanneer u lokaal werkt, moet u uw lokale opslagplaats synchroniseren voordat u uw werkbranch maakt. De werkvertakking moet worden gemaakt op basis van een up-to-datumkopie van de main vertakking.

Alle pull-aanvragen moeten zich richten op de main vertakking. Dien geen wijzigingen in de live branch in. Wijzigingen die in de main vertakking zijn aangebracht, worden samengevoegd in live en overschrijven daarbij eventuele wijzigingen die in live zijn aangebracht.

Het pull-aanvraagproces beter laten werken voor iedereen

Hoe eenvoudiger en gerichter je je pull request kunt maken, hoe sneller deze kan worden beoordeeld en samengevoegd.

Vermijd pull-aanvragen die grote aantallen bestanden bijwerken of niet-gerelateerde wijzigingen bevatten

Vermijd het maken van pull requests die niet-gerelateerde veranderingen bevatten. Scheid kleine updates voor bestaande artikelen van nieuwe artikelen of belangrijke herschrijven. Werk aan deze wijzigingen in afzonderlijke werkbranches.

Bulkwijzigingen maken Pull Requests met grote aantallen gewijzigde bestanden. Beperk uw PR's tot maximaal 50 veranderde bestanden. Grote PR's zijn moeilijk te controleren en vatbaarder voor fouten.

Bestanden hernoemen of verwijderen

Er moet een probleem aan de PR zijn gekoppeld wanneer u bestanden hernoemt of verwijdert. Dit probleem moet de noodzaak bespreken om de bestanden te wijzigen of te verwijderen.

Vermijd het combineren van toevoegingen of wijzigingen van inhoud met bestandsnamen en verwijderingen. Elk bestand dat u hernoemt of verwijdert, moet worden toegevoegd aan het juiste omleidingsbestand. Werk indien mogelijk alle bestanden bij die een koppeling maken naar de hernoemde of verwijderde inhoud, inclusief eventuele inhoudsbestanden.

Vermijd het bewerken van configuratiebestanden voor opslagplaatsen

Vermijd het wijzigen van configuratiebestanden voor opslagplaatsen. Beperk uw wijzigingen waar mogelijk tot de Markdown-inhoudsbestanden en eventuele ondersteunende afbeeldingsbestanden die nodig zijn voor de inhoud.

Onjuiste wijzigingen in opslagplaatsconfiguratiebestanden kunnen de build verbreken, beveiligingsproblemen of toegankelijkheidsproblemen veroorzaken of organisatiestandaarden schenden. Configuratiebestanden voor opslagplaatsen zijn bestanden die overeenkomen met een of meer van deze patronen:

• *.yml
• .github/**
• .localization-config
• .openpublishing*
• LICENSE*
• reference/docfx.json
• reference/mapping/**
• tests/**
• ThirdPartyNotices
• tools/**

Wijzig deze bestanden niet voor veiligheid en beveiliging. Als u denkt dat een van deze bestanden moet worden gewijzigd, kunt u een probleem indienen. Nadat de onderhouders het probleem hebben gevonden, brengen ze de juiste wijzigingen aan.

Gebruik de pull request-sjabloon

Wanneer u een PR maakt, wordt er automatisch een sjabloon ingevoegd in de tekst van de PR. Dit ziet er als volgt uit:

# PR Summary

<!--
    Delete this comment block and summarize your changes and list
    related issues here. For example:

    This changes fixes problem X in the documentation for Y.

    - Fixes #1234
    - Resolves #1235
-->

## PR Checklist

<!--
    These items are mandatory. For your PR to be reviewed and merged,
    ensure you have followed these steps. As you complete the steps,
    check each box by replacing the space between the brackets with an
    x or by clicking on the box in the UI after your PR is submitted.
-->

- [ ] **Descriptive Title:** This PR's title is a synopsis of the changes it proposes.
- [ ] **Summary:** This PR's summary describes the scope and intent of the change.
- [ ] **Contributor's Guide:** I have read the [contributors guide][contrib].
- [ ] **Style:** This PR adheres to the [style guide][style].

<!--
    If your PR is a work in progress, please mark it as a draft or
    prefix it with "(WIP)" or "WIP:"

    This helps us understand whether or not your PR is ready to review.
-->

[contrib]: /powershell/scripting/community/contributing/overview
[style]: /powershell/scripting/community/contributing/powershell-style-guide

Schrijf in de sectie 'PR-samenvatting' een korte samenvatting van uw wijzigingen en vermeld eventuele gerelateerde problemen op basis van hun probleemnummer, zoals #1234. Als uw pull-aanvraag het probleem oplost of oplost, gebruikt u de functie voor automatisch sluiten van GitHub, zodat het probleem automatisch wordt gesloten wanneer uw pull-aanvraag wordt samengevoegd.

Bekijk de items in de sectie "Checklist voor PR" en vink ze af wanneer u ze voltooit. U moet de aanwijzingen volgen en elk item controleren zodat het team uw pull-verzoek kan goedkeuren.

Als uw pull-aanvraag nog in ontwikkeling is, stelt u deze in op conceptmodus of laat u de titel van uw pull-aanvraag voorafgaan aan WIP.

Verwachtingen Opmerkingen

Nadat u uw pull-aanvraag hebt ingediend, plaatst een bot commentaar op uw pull-aanvraag. De opmerking biedt resources en stelt verwachtingen in voor de rest van het proces. We kunnen deze opmerking regelmatig bijwerken, dus controleer altijd de opmerking, zelfs als dit niet uw eerste bijdrage is.

Docs PR-validatieservice

De Docs PR-validatieservice is een GitHub-app waarmee validatieregels voor uw wijzigingen worden uitgevoerd. U moet eventuele fouten of waarschuwingen oplossen die door de validatieservice zijn gerapporteerd.

In de volgende stappen wordt het validatiegedrag beschreven:

1. U dient een pull-aanvraag in.

2. In de GitHub-opmerking die de status aangeeft van de controles die zijn ingeschakeld in de opslagplaats. In dit voorbeeld zijn er twee controles ingeschakeld: Doorvoervalidatie en OpenPublishing.Build:

   

   De build kan worden doorgegeven, zelfs als de doorvoervalidatie mislukt.

3. Selecteer Details voor meer informatie. Op de pagina Details worden alle validatiecontroles weergegeven die zijn mislukt en bevat informatie over het oplossen van de problemen.

4. Wanneer de validatie is geslaagd, wordt de volgende opmerking toegevoegd aan de pull-aanvraag:

   

Opmerking

Als u een externe inzender bent (geen Microsoft-werknemer), hebt u geen toegang tot de gedetailleerde buildrapporten of preview-koppelingen.

Wanneer de pull-aanvraag wordt gecontroleerd, wordt u mogelijk gevraagd om wijzigingen aan te brengen of waarschuwingsberichten voor validatie op te lossen. Het PowerShell-Docs team kan u helpen bij het begrijpen van validatiefouten en redactionele vereisten.

GitHub Actions (GitHub-acties)

Verschillende GitHub Actions worden uitgevoerd op basis van uw wijzigingen om u en de revisoren context te valideren en te bieden.

Controlelijstcontrole

Als uw pull-aanvraag zich niet in de conceptmodus bevindt en niet wordt voorafgegaan door WIP, inspecteert een GitHub-actie uw pull-aanvraag om te controleren of u elk item in de controlelijst van de pull-aanvraagsjabloon hebt geselecteerd. De onderhouders controleren of samenvoegen uw pull-aanvraag pas nadat u de controlelijst hebt voltooid. De controlelijstitems zijn verplicht.

Verificatie van autorisatie

Als uw pull-aanvraag is gericht op de live vertakking of een configuratiebestand voor de opslagplaats wijzigt, controleert een GitHub-actie uw machtigingen om te controleren of u gemachtigd bent om deze wijzigingen in te dienen.

Alleen opslagplaatsbeheerders zijn gemachtigd om de live vertakking te richten of configuratiebestanden voor opslagplaatsen te wijzigen.

Rapportage over wijzigingen in versies van inhoud

Als uw pull-aanvraag alle versie-inhoud toevoegt, verwijdert of wijzigt, analyseert een GitHub Action uw wijzigingen en schrijft een rapport met een samenvatting van de typen wijzigingen die zijn aangebracht in versieversies van inhoud.

Dit rapport kan weergeven of er andere versies van de bestanden zijn die u in deze pull-aanvraag moet bijwerken.

Ga als volgende te werk om het inhoudsrapport met versiebeheer voor uw pull-aanvraag te vinden:

1. Selecteer het tabblad Controles op uw pull-aanvraagpagina.
2. Selecteer de taak Rapportage in de lijst met taken.
3. Selecteer de '...' in de rechterbovenhoek.
4. Selecteer 'Taakoverzicht weergeven'.

Volgende stappen

PowerShell-Docs stijlgids

Aanvullende bronnen

Hoe we pull-aanvragen beheren