Pull-aanvragen beheren

In dit artikel wordt beschreven hoe we pull-aanvragen beheren in de PowerShell-Docs opslagplaats. Dit artikel is ontworpen als functiehulp voor leden van het PowerShell-Docs team. Het wordt hier gepubliceerd om procestransparantie te bieden voor onze publieke inzenders.

Aanbevolen procedures

• De persoon die de pull-aanvraag indient, mag de pull-aanvraag niet samenvoegen zonder een peerbeoordeling.
• Wijs de peer-revisor toe wanneer de pull-aanvraag wordt ingediend. Met vroege toewijzing kan de revisor sneller reageren met redactionele opmerkingen.
• Gebruik opmerkingen om de aard van de wijziging of het aangevraagde type beoordeling te beschrijven. Zorg ervoor dat @mention de revisor. Als de wijziging bijvoorbeeld klein is en u geen volledige technische beoordeling nodig hebt, legt u dit uit in een opmerking.

Stappen voor pr-proces

1. Schrijver: pull-aanvraag maken
   • Eventuele problemen koppelen die zijn opgelost door de pull-aanvraag
   • De functie autoclose van GitHub gebruiken om het probleem te sluiten
2. Schrijver: Peer-revisor toewijzen
3. Revisor: controlelezen en opmerkingen (indien nodig)
4. Schrijver: Feedback beoordelen opnemen
5. Beide: Preview-weergave controleren
6. Beide: Validatierapport controleren - waarschuwingen en fouten oplossen
7. Schrijver: Opmerking bij afmelden toevoegen (inclusief Acrolinx-informatie)
8. Revisor: Beoordeling 'Goedgekeurd' markeren
9. Beheerder van opslagplaats: pull-aanvraag samenvoegen (zie hieronder voor criteria)

Controlelijst voor inhoudsrevisor

Zie de redactionele controlelijst voor een uitgebreidere lijst.

• Spellingcontrole voor grammatica, stijl, concisie, technische nauwkeurigheid
• Zorg ervoor dat voorbeelden nog steeds van toepassing zijn op de doelversie
• Preview-weergave controleren
• Metagegevens controleren - ms.date, ms.assetid verwijderen, vereiste velden controleren
• De juistheid van Markdown valideren
  • Zie de stijlgids voor inhoudsspecifieke opmaakregels
• U kunt voorbeelden als volgt opnieuw organiseren:
  • Inleidingszin(en)
  • Code en uitvoer
  • Gedetailleerde uitleg van code (indien nodig)
• Hyperlinks controleren op nauwkeurigheid
  • TechNet-/MSDN-koppelingen vervangen of verwijderen
  • Minimaal aantal omleidingen naar doel garanderen
  • Https controleren
  • Correct koppelingstype
    • Bestandskoppelingen voor lokale bestanden
    • URL-koppelingen voor bestanden buiten de docset
  • Landinstellingen verwijderen uit URL's
  • URL's vereenvoudigen die verwijzen naar docs.microsoft.com

Proces voor vertakkingssamenvoeging

De main vertakking is de enige vertakking die is samengevoegd in live. Samenvoegingen van kortlevende (werkende) takken moeten worden verpletterd.

Samenvoegen van/naar	release-branch	main	Live
working-branch	squash en samenvoegen	squash en samenvoegen	Niet toegestaan
release-branch	—	samenvoegen	Niet toegestaan
main	Rebase	—	samenvoegen

Controlelijst voor pr-fusie

• Inhoudsbeoordeling voltooid
• Juiste doelbranch voor de wijziging
• Geen samenvoegingsconflicten
• Alle validatie- en buildstappas
  • Waarschuwingen en suggesties moeten worden opgelost (zie Opmerkingen voor uitzonderingen)
  • Geen verbroken koppelingen
• Samenvoegen op basis van tabel

Notities

De volgende waarschuwingen kunnen niet worden genegeerd:

Can't find service name for `<version>/<modulepath>/About/About.md`

Metadata with following name(s) are not allowed to be set in Yaml header, or as file level
metadata in docfx.json, or as global metadata in docfx.json: `locale`. They are generated by
Docs platform, so the values set in these 3 places will be ignored. Please remove them from all
3 places to resolve the warning.

Wanneer een pull-aanvraag wordt samengevoegd, wordt de HEAD van de doelbranch gewijzigd. Open PULL's die zijn gebaseerd op de vorige HEAD zijn nu verouderd. De verouderde pull-aanvraag kan worden samengevoegd met beheerdersrechten om de samenvoegwaarschuwingen in GitHub te overschrijven. Dit is veilig om te doen als de eerder samengevoegde pull-aanvraag(s) dezelfde bestanden niet hebben aangeraakt. Als u echter op de knop Vertakking bijwerken klikt, is de veiligste optie. Mogelijk hebt u onopgeloste conflicten die moeten worden opgelost.

Publiceren naar Live

Periodiek moeten de wijzigingen in de main vertakking worden gepubliceerd naar de livewebsite.

• De main vertakking wordt samengevoegd met live elke weekdag om 13:00 PST.
• De main vertakking moet worden samengevoegd naar live een belangrijke wijziging.
  • Wijzigingen in 50 of meer bestanden
  • Na het samenvoegen van een releasebranch
  • Wijzigingen in configuraties voor opslagplaatsen of docsets (docfx.json, OPS-configuraties, buildscripts, enzovoort)
  • Wijzigingen in het omleidingsbestand
  • Wijzigingen in de toc
  • Na het samenvoegen van een projectvertakking (inhoudsherhaling, bulkupdate, enzovoort)