So übermitteln Sie Pullanforderungen

Um Änderungen an Inhalten vorzunehmen, senden Sie einen Pull Request (PR) von Ihrem Fork. Eine Pullanforderung muss überprüft werden, bevor sie zusammengeführt werden kann. Um optimale Ergebnisse zu erzielen, überprüfen Sie die redaktionelle Checkliste , bevor Sie Ihre Pullanfrage einreichen.

Verwenden von Git-Verzweigungen

Die Standardverzweigung für PowerShell-Docs ist die main Verzweigung. Änderungen, die in Arbeitszweigen vorgenommen werden, werden in den main Branch zusammengeführt, bevor sie veröffentlicht werden. Die main Filiale wird jeden Wochentag um 3:00 Uhr (Pacific Time) in die live Filiale zusammengeführt. Die live Branch enthält den Inhalt, der learn.microsoft.com veröffentlicht wird.

Erstellen Sie vor dem Starten von Änderungen eine Arbeitszweigstelle in Ihrer lokalen Kopie des PowerShell-Docs-Repositorys. Achten Sie beim lokalen Arbeiten darauf, Ihr lokales Repository zu synchronisieren, bevor Sie Ihren Arbeits-Branch erstellen. Die Arbeits-Branch sollte aus einer up-to-Datumskopie des main Branch erstellt werden.

Alle Pullanforderungen sollten auf die main Verzweigung abzielen. Senden Sie keine Änderungen an den live Branch. Änderungen, die in der main-Verzweigung vorgenommen wurden, werden in die live-Verzweigung integriert, wobei alle Änderungen überschrieben werden, die an der live-Verzweigung vorgenommen wurden.

Sorgen Sie dafür, dass der Pull-Anforderungsprozess für jeden besser funktioniert

Je einfacher und fokussierter Sie Ihre PR machen können, desto schneller kann sie überprüft und zusammengeführt werden.

Vermeiden von Pullanforderungen, die eine große Anzahl von Dateien aktualisieren oder nicht verknüpfte Änderungen enthalten

Vermeiden Sie das Erstellen von PRs, die nicht verknüpfte Änderungen enthalten. Trennen Sie kleinere Aktualisierungen vorhandener Artikel von neuen Artikeln oder großen Neuschreibungen. Arbeiten Sie an diesen Änderungen in separaten Arbeitszweigen.

Massenänderungen führen zu PRs mit vielen geänderten Dateien. Beschränken Sie Ihre PRs auf maximal 50 geänderte Dateien. Große PRs sind schwer zu überprüfen und anfälliger für Fehler.

Umbenennen oder Löschen von Dateien

Beim Umbenennen oder Löschen von Dateien muss ein Problem mit der PR verbunden sein. Dieses Problem muss die Notwendigkeit diskutieren, die Dateien umzubenennen oder zu löschen.

Vermeiden Sie das Mischen von Hinzufügungen oder Änderungen von Inhalten mit Umbenennungen und Löschungen von Dateien. Jede Datei, die Sie umbenennen oder löschen, muss der entsprechenden Umleitungsdatei hinzugefügt werden. Aktualisieren Sie nach Möglichkeit alle Dateien, die mit dem umbenannten oder gelöschten Inhalt verknüpft sind, einschließlich aller Inhaltsverzeichnisdateien.

Vermeiden der Bearbeitung von Repositorykonfigurationsdateien

Vermeiden Sie das Ändern von Repositorykonfigurationsdateien. Beschränken Sie Die Änderungen, sofern möglich, auf die Markdown-Inhaltsdateien und alle unterstützenden Bilddateien, die für den Inhalt erforderlich sind.

Falsche Änderungen an Repositorykonfigurationsdateien können den Build unterbrechen, Sicherheitsrisiken oder Barrierefreiheitsprobleme einführen oder organisationsinterne Standards verletzen. Repositorykonfigurationsdateien sind alle Dateien, die einem oder mehreren dieser Muster entsprechen:

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

Ändern Sie diese Dateien nicht, um die Sicherheit und den Schutz zu gewährleisten. Wenn Sie denken, dass eine dieser Dateien geändert werden sollte, melden Sie ein Problem. Nachdem die Betreuer das Problem triagen, nehmen sie die entsprechenden Änderungen vor.

Verwenden der PR-Vorlage

Wenn Sie eine PR erstellen, wird automatisch eine Vorlage in den PR-Textkörper eingefügt. Es sieht wie folgt aus:

# 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

Schreiben Sie im Abschnitt "PR-Zusammenfassung" eine kurze Zusammenfassung Ihrer Änderungen und listen Sie alle zugehörigen Probleme anhand ihrer Problemnummer auf, wie #1234. Wenn Ihre PR das Problem behebt oder löst, verwenden Sie das Autoclose-Feature von GitHub, um das Problem automatisch zu schließen, wenn Ihre PR zusammengeführt wird.

Überprüfen Sie die Punkte im Abschnitt "PR-Checkliste" und haken Sie sie ab, nachdem Sie jeden Punkt erledigt haben. Sie müssen die Anweisungen befolgen und jedes Element überprüfen, um Ihre PR zu genehmigen.

Wenn Es sich bei Ihrer PR um eine laufende Arbeit handelt, legen Sie sie auf entwurfsmodus fest oder stellen Sie Ihrem PR-Titel das Präfix voran WIP.

Erwartungen-Kommentar

Nachdem Sie Ihre PR eingereicht haben, kommentiert ein Bot Ihre PR. Der Kommentar stellt Ressourcen bereit und legt Die Erwartungen für den Rest des Prozesses fest. Möglicherweise aktualisieren wir diesen Kommentar regelmäßig, also überprüfen Sie immer den Kommentar, auch wenn dies nicht Ihr erster Beitrag ist.

Docs PR-Überprüfungsdienst

Der Docs PR-Überprüfungsdienst ist eine GitHub-App, die Gültigkeitsprüfungsregeln für Ihre Änderungen ausführt. Sie müssen alle Fehler oder Warnungen beheben, die vom Überprüfungsdienst gemeldet wurden.

Die folgenden Schritte beschreiben das Überprüfungsverhalten:

1. Sie übermitteln eine PR.

2. Im GitHub-Kommentar, der den Status der im Repository aktivierten "Checks" angibt. In diesem Beispiel sind zwei Überprüfungen aktiviert: "Commit-Überprüfung" und "OpenPublishing.Build":

   

   Der Build kann auch dann erfolgen, wenn die Commit-Überprüfung fehlschlägt.

3. Wählen Sie "Details" aus, um weitere Informationen zu erhalten. Auf der Seite "Details " werden alle Überprüfungen angezeigt, die fehlgeschlagen sind, und enthält Informationen zum Beheben der Probleme.

4. Wenn die Überprüfung erfolgreich ist, wird der PR der folgenden Kommentar hinzugefügt:

   

Hinweis

Wenn Sie ein externer Mitwirkender sind (kein Microsoft-Mitarbeiter), haben Sie keinen Zugriff auf die detaillierten Buildberichte oder Vorschaulinks.

Wenn die PR überprüft wird, werden Sie möglicherweise aufgefordert, Änderungen vorzunehmen oder Validierungswarnungen zu beheben. Das PowerShell-Docs Team kann Ihnen helfen, Validierungsfehler und redaktionelle Anforderungen zu verstehen.

GitHub-Aktionen

Mehrere verschiedene GitHub-Aktionen werden für Ihre Änderungen ausgeführt, um Kontext für Sie und die Prüfer zu überprüfen und bereitzustellen.

Prüflistenüberprüfung

Wenn sich Ihre PR nicht im Entwurfsmodus befindet und nicht mit WIP präfixiert ist, dann überprüft eine GitHub-Aktion Ihre PR, um sicherzustellen, dass Sie jedes Element in der Checkliste der PR-Vorlage ausgewählt haben. Die Betreuer überprüfen oder führen Ihre PR erst zusammen, wenn Sie die Checkliste abgeschlossen haben. Die Checklistenelemente sind obligatorisch.

Autorisierungsüberprüfung

Wenn Ihre PR auf die live Verzweigung ausgerichtet ist oder Repositorykonfigurationsdateien ändert, überprüft eine GitHub-Aktion Ihre Berechtigungen, um zu überprüfen, ob Sie berechtigt sind, diese Änderungen zu übermitteln.

Nur Repositoryadministratoren sind berechtigt, den live Branch anzusprechen oder die Repositorykonfigurationsdateien zu ändern.

Bericht über Änderungen von versionierten Inhalten

Wenn Ihre PR alle versionsgeschützten Inhalte hinzufügt, entfernt oder ändert, analysiert eine GitHub-Aktion Ihre Änderungen und schreibt einen Bericht, der die Arten von Änderungen zusammenfasst, die an versionsierten Inhalten vorgenommen wurden.

Dieser Bericht kann anzeigen, ob es andere Versionen der Dateien gibt, die Sie in dieser PR aktualisieren müssen.

So finden Sie den Versionsinhaltsbericht für Ihre PR:

1. Wählen Sie auf Ihrer PR-Seite die Registerkarte "Prüfungen" aus.
2. Wählen Sie den Auftrag "Berichterstellung" aus der Liste der Aufträge aus.
3. Wählen Sie in der oberen rechten Ecke die Schaltfläche "..." aus.
4. Wählen Sie "Auftragszusammenfassung anzeigen" aus.

Nächste Schritte

PowerShell-Docs Styleguide

Weitere Ressourcen

So verwalten wir Pullanforderungen