次の方法で共有


pull request を送信する方法

コンテンツを変更するには、フォークから pull request (PR) を送信します。 マージする前に、プル要求を確認する必要があります。 最良の結果を得るには、pull request を送信する前に 編集チェックリスト を確認してください。

Git ブランチの使用

PowerShell-Docs の既定のブランチは、 main ブランチです。 作業ブランチで行われた変更は、公開される前に main ブランチにマージされます。 mainブランチは、平日の毎日午後 3 時 (太平洋時間) にlive ブランチにマージされます。 live ブランチには、learn.microsoft.comに発行されたコンテンツが含まれています。

変更を開始する前に、PowerShell-Docs リポジトリのローカル コピーに作業ブランチを作成します。 ローカルで作業する場合は、作業ブランチを作成する前に、必ずローカル リポジトリを同期してください。 作業ブランチは、 main ブランチの up-to-date コピーから作成する必要があります。

すべてのプル要求は、 main ブランチを対象とする必要があります。 live ブランチに変更を送信しないでください。 mainブランチで行われた変更はliveにマージされ、liveに加えられた変更はすべて上書きされます。

pull request プロセスをすべてのユーザーにとってより適切に機能させる

PR を簡単かつ集中的に作成すればするほど、レビューとマージが速くなります。

多数のファイルを更新したり、関連のない変更を含めたりするプル要求を回避する

関係のない変更を含む PR の作成は避けてください。 既存の記事に対する軽微な更新は、新しい記事や主要な書き換えから分離します。 個別の作業ブランチでこれらの変更に取り組みます。

一括変更では、多数の変更されたファイルを含む PR が作成されます。 PRの変更ファイル数を最大50個に制限してください。 大規模な PR は確認が難しく、エラーが含まれる傾向があります。

ファイルの名前変更または削除

ファイルの名前を変更または削除するときに、PR に関連する問題が発生している必要があります。 この問題では、ファイルの名前を変更または削除する必要性について説明する必要があります。

コンテンツの追加や変更とファイルの名前変更と削除を混在させないでください。 名前を変更または削除するすべてのファイルは、適切なリダイレクト ファイルに追加する必要があります。 可能な場合は、TOC ファイルを含め、名前を変更または削除したコンテンツにリンクするファイルを更新します。

リポジトリ構成ファイルの編集を避ける

リポジトリ構成ファイルの変更は避けてください。 可能な限り、Markdown コンテンツ ファイルと、コンテンツに必要なサポート イメージ ファイルに変更を制限します。

リポジトリ構成ファイルを正しく変更すると、ビルドが中断されたり、脆弱性やアクセシビリティの問題が発生したり、組織の標準に違反したりする可能性があります。 リポジトリ構成ファイルは、次の 1 つ以上のパターンに一致するファイルです。

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

安全とセキュリティのために、これらのファイルを変更しないでください。 これらのファイルのいずれかを変更する必要があると思われる場合は、 問題を提出してください。 メンテナンス担当者は問題をトリアージした後、適切な変更を行います。

PR テンプレートを使用する

PR を作成すると、テンプレートが自動的に PR 本文に挿入されます。 次のようになります。

# 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

[PR の概要] セクションで、変更の簡単な概要を記述し、問題番号 ( #1234 など) ごとに関連する問題を一覧表示します。 PR で問題が修正または解決された場合は、GitHub の 自動クローズ 機能を使用して、PR がマージされたときに問題が自動的に閉じるようにします。

「PR チェックリスト」セクションの項目を確認し、各項目を完了したらチェックを付けてください。 指示に従い、チームが PR を承認するための各項目を確認する必要があります。

PR が進行中の場合は、 下書きモード に設定するか、PR タイトルに WIP のプレフィックスを付けます。

期待に関するコメント

プルリクエストを送信すると、ボットがあなたのプルリクエストにコメントを残します。 このコメントはリソースを提供し、プロセスの残りの部分に対する期待値を設定します。 このコメントは定期的に更新される可能性があるため、最初の投稿ではない場合でも、必ずコメントを確認してください。

期待されるコメントの例

Docs PR 検証サービス

Docs PR 検証サービスは、変更に対して検証規則を実行する GitHub アプリです。 検証サービスによって報告されたエラーまたは警告を修正する必要があります。

次の手順では、検証動作の概要を示します。

  1. PR を送信します。

  2. リポジトリで有効になっている "チェック" の状態を示す GitHub コメント。 この例では、"コミット検証" と "OpenPublishing.Build" という 2 つのチェックが有効になっています。

    検証の状態 - 一部のチェックが失敗しました

    コミットの検証が失敗した場合でも、ビルドは成功します。

  3. 詳細については、[ 詳細 ] を選択してください。 [詳細] ページには、失敗したすべての検証チェックが表示され、問題の修正方法に関する情報が表示されます。

  4. 検証が成功すると、次のコメントが PR に追加されます。

    検証の状態: 成功

外部共同作成者 (Microsoft の従業員ではない) の場合は、詳細なビルド レポートやプレビュー リンクにアクセスできません。

PR がレビューされると、変更を行うか、検証の警告メッセージを修正するように求められる場合があります。 PowerShell-Docs チームは、検証エラーと編集要件を理解するのに役立ちます。

GitHub のアクション

変更に対していくつかの異なる GitHub Actions が実行され、ユーザーとレビュー担当者にコンテキストを検証して提供します。

チェックリストの検証

PR が ドラフト モード ではなく、プレフィックスに WIP が付いていない場合、GitHub アクションによって PR が検査され、PR テンプレートのチェックリスト内のすべての項目が選択されたことを確認します。 メンテナンス担当者は、チェックリストを完了するまで PR を確認またはマージしません。 チェックリスト項目は必須です。

承認の検証

PR が live ブランチをターゲットにしている場合、またはリポジトリ構成ファイルを変更する場合、GitHub アクションはアクセス許可をチェックして、それらの変更を送信する権限があることを確認します。

liveブランチを対象とするか、リポジトリ構成ファイルを変更する権限を持つのは、リポジトリ管理者だけです。

バージョン管理されたコンテンツ変更レポート

PR がバージョン管理されたコンテンツを追加、削除、または変更した場合、GitHub Action によって変更内容が分析され、バージョン管理されたコンテンツに加えられた変更の種類を要約したレポートが書き込まれます。

このレポートには、この PR で更新する必要がある他のバージョンのファイルがあるかどうかを示すことができます。

PR のバージョン付きコンテンツ レポートを見つけるには、次の手順に従ってください:

  1. PR ページの [チェック] タブを選択します。
  2. ジョブの一覧から [レポート] ジョブを選択します。
  3. 右上の「...」ボタンを選択します。
  4. [ジョブの概要の表示] を選択します。

バージョン管理されたコンテンツ変更レポートの例

次のステップ

PowerShell-Docs スタイル ガイド

その他のリソース

プル要求を管理する方法