Freigeben über

Verwalten von Pullanforderungen

In diesem Artikel wird dokumentiert, wie Pullanforderungen im PowerShell-Docs Repository verwaltet werden. Dieser Artikel ist eine Arbeitshilfe für Mitglieder des PowerShell-Docs Teams. Wir veröffentlichen diese Informationen hier, um Prozesstransparenz für unsere öffentlichen Mitwirkenden bereitzustellen.

Bewährte Methoden

  • Fordern Sie eine Überprüfung an. Die Person, die die PR übermittelt, sollte die PR nicht ohne Peer Review zusammenführen.
  • Weisen Sie den Peer-Reviewer zu, wenn die PR übermittelt wird. Eine frühe Aufgabe ermöglicht es dem Prüfer, schneller mit redaktionellen Anmerkungen zu antworten.
  • Verwenden Sie Kommentare, um die Art der übermittelten Änderung zu beschreiben. Wenn die Änderung z. B. geringfügig ist, erklären Sie die Änderung und benötigen keine vollständige technische Überprüfung. Achten Sie unbedingt auf @mention den Prüfer.
  • Verwenden Sie das Kommentarvorschlagsfeature, um dem Autor die Annahme der vorgeschlagenen Änderung zu erleichtern. Weitere Informationen finden Sie unter Überprüfen vorgeschlagener Änderungen in einer Pullanforderung.

PR-Prozessschritte

  1. Writer: Erstelle Öffentlichkeitsarbeit
    • Ausfüllen der PR-Vorlage
    • Verknüpfen von Problemen, die von der PR behoben wurden
    • Verwenden des Autoclose-Features von GitHub zum Schließen des Problems
    • Arbeiten Sie jeden Punkt in der Checkliste durch und haken Sie ihn ab.
  2. Writer: Peer Reviewer zuweisen
  3. Prüfer: Korrekturlesen und Kommentare (nach Bedarf)
  4. Writer: Integrieren von Rezensionsfeedback
  5. Beides: Vorschau-Rendering überprüfen
  6. Beide: Validierungsbericht überprüfen – Warnungen und Fehler beheben
  7. Prüfer: Prüfung als "Genehmigt" markieren
  8. Repo Maintainer: Zusammenführen PR

Prüfliste für inhaltsprüfer

Eine ausführlichere Liste finden Sie in der redaktionellen Checkliste .

  • Korrekturlesen für Grammatik, Stil, Konzision, technische Genauigkeit
  • Stellen Sie sicher, dass Die Beispiele weiterhin für die Zielversion gelten
  • Überprüfen des Vorschau-Renderings
  • Überprüfen von Metadaten - ms.date, entfernen ms.assetid, sicherstellen, dass erforderliche Felder vorhanden sind
  • Überprüfen der Markdown-Korrektheit
    • Siehe Formatvorlagenhandbuch für inhaltsspezifische Formatierungsregeln
  • Reorganisieren Sie Beispiele wie folgt:
    • Einführungsabsatz
    • Code und Ausgabe
    • Ausführliche Erläuterung des Codes (nach Bedarf)
  • Überprüfen von Links auf Genauigkeit
    • Ersetzen oder Entfernen von TechNet/MSDN-Links
    • Die Anzahl der Umleitungen zum Ziel minimieren.
    • Sicherstellen von HTTPS
    • Richtiger Verknüpfungstyp
      • Dateilinks für lokale Dateien
      • URL-Links für Dateien außerhalb des Docsets
    • Gebietsschemas aus URLs entfernen
    • Vereinfachen von URLs, die auf learn.microsoft.com
  • Überprüfen, ob Versionsinhalte in allen Versionen korrekt sind

Verzweigungszusammenführungsprozess

Die main Verzweigung ist die einzige Verzweigung, die in live zusammengeführt werden soll. Zusammenführungen aus kurzlebigen (arbeitsfähigen) Zweigniederlassungen sollten vor der Zusammenführung mainabgegrenzt werden.

Zusammenführen von/zu release-branch Haupt leben
Arbeitszweig Squash und Zusammenführen Squash und Zusammenführen Nicht zulässig
release-branch — zusammenführen Nicht zulässig
Haupt Rebase ausführen — zusammenführen

Checkliste für pr-Fusionen

  • Inhaltsüberprüfung abgeschlossen
  • Den Zielzweig für die Änderung korrigieren
  • Keine Zusammenführungskonflikte
  • Alle Überprüfungs- und Build-Schritte wurden erfolgreich durchgeführt.
    • Warnungen und Vorschläge sollten behoben werden (siehe Hinweise zu Ausnahmen)
    • Keine fehlerhaften Verknüpfungen
    • Die Checkliste-Aktion wurde ausgeführt und erfolgreich abgeschlossen.
    • Wenn eine Autorisierungsprüfung ausgelöst wurde, hat sie bestanden.
  • Zusammenführen gemäß der Tabelle

Hinweise

Die folgenden Warnungen können ignoriert werden:

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.

Wenn eine PR zusammengeführt wird, wird der HEAD des Zielzweigs geändert. Alle geöffneten PRs, die auf dem vorherigen HEAD basieren, sind jetzt veraltet. Ein Maintainer hat das Recht, die Zusammenführungswarnungen außer Kraft zu setzen und die veraltete PR in GitHub zusammenzuführen. Das Zusammenführen einer veralteten PR ist sicher, wenn die zuvor zusammengeführten PRs die gleichen Dateien nicht berührt haben.

Um die PR zu aktualisieren, klicken Sie auf die Schaltfläche Branch aktualisieren. Wählen Sie Aktualisieren mit Neubasis aus. Weitere Informationen finden Sie unter Aktualisieren des Pull-Request-Zweigs.

Publizieren auf Live-Plattform

In regelmäßigen Abständen müssen die in der main Filiale gesammelten Änderungen auf der Live-Website veröffentlicht werden.

  • Die main-Branch wird an live jedem Wochentag um 15:00 Uhr PST gemergt.
  • Die main Verzweigung sollte nach einer erheblichen Änderung zu live zusammengeführt werden.
    • Änderungen an 50 oder mehr Dateien
    • Nach der Zusammenführung eines Release-Branch
    • Änderungen an Repository- oder Docset-Konfigurationen (docfx.json, OPS-Konfigurationen, Buildskripts usw.)
    • Änderungen an der Umleitungsdatei
    • Änderungen am Inhaltsverzeichnis
    • Durch das Zusammenführen eines "Projekt"-Branches (Inhaltsneuorganisation, Massenaktualisierung usw.)
  • Last updated on