{"meta":{"title":"スタックされたプル要求","intro":"GitHubでのスタック プル要求の機能に関する規則と要件。","product":"Pull Request","breadcrumbs":[{"href":"/ja/enterprise-cloud@latest/pull-requests","title":"Pull Request"},{"href":"/ja/enterprise-cloud@latest/pull-requests/reference","title":"Reference"},{"href":"/ja/enterprise-cloud@latest/pull-requests/reference/stacked-pull-requests","title":"スタックされたプル要求"}],"documentType":"article"},"body":"# スタックされたプル要求\n\nGitHubでのスタック プル要求の機能に関する規則と要件。\n\n> \\[!NOTE] この機能はパブリック プレビュー段階であり、変更される可能性があります。\n\nスタックは、同じリポジトリ内の一連のプル要求です。各プル要求は、その下のプル要求のブランチを対象とし、1 つのブランチ (通常はメイン ブランチ) に配置される順序付きチェーンを形成します。 1 つの大きなプル要求の代わりに、一連の小さなプル要求を取得します。 各プル要求には独自のフォーカスされた差分があるため、チームメイトは各レイヤーを個別に確認して承認できます。\n\nスタック内のすべてのプル要求は、直接ターゲットとするブランチに関係なく、 **スタックのベース** (通常は `main` ) の規則に対して評価されます。 つまり、ミッドスタック プル要求は、下位プル要求と同じ標準に保持されます。\n\n> \\[!NOTE]\n>\n> * スタック プル要求では、すべてのブランチが同じリポジトリに存在する必要があります。 クロスフォーク スタックはサポートされていません。\n> * GitHub Desktopでは、スタックプル要求はサポートされていません。\n\n## Stacked pull requests availability\n\n`gh stack`\nGitHub CLI拡張機能は、ローカル開発ワークフローを処理します。 正しい依存関係の順序で分岐を作成および追跡し、ブランチのリベースを維持し、ブランチをプッシュし、プル要求を作成してリンクし、レイヤー間を移動します。\n\nGitHub CLI は必須ではありません。 基になる Git 操作は標準であり、代わりに GitHub Web サイトからスタックを作成できます。\n\nJujutsu や Sapling などの他のツールを使用してローカル ブランチを管理およびプッシュする場合でも、 GitHub CLI または GitHub Web サイトを使用して、それらのブランチからのプル要求のスタックを開くことができます。 「[積み上げプル要求で他のツールを使用する](/ja/enterprise-cloud@latest/pull-requests/reference/use-other-tools-with-stacked-pull-requests)」を参照してください。\n\n## スタックされたプル要求のトランク\n\nスタックの **トランク** は、下位プル要求のベース ブランチです。 スタック内の他のすべてのプル要求は、その上に構築されます。 トランクの既定値はリポジトリの既定のブランチ ( `main` など) ですが、リリース ブランチや有効期間の長い機能ブランチなど、任意のブランチにすることができます。\n\nトランクを設定するには:\n\n* **GitHub CLIから**`--base BRANCH` オプションを `gh stack init` コマンド (たとえば、`gh stack init --base release auth-layer`) に渡します。\n* **GitHub Web サイトから**、トランクとして必要なブランチに対する下位プル要求を作成します。 スタックの残りの部分は、その上に構築されます。\n\nブランチ保護規則、必要なチェック、CI はすべて、既定のブランチだけでなく、スタックターゲットのトランクに対しても評価されます。\n\n## ブランチ保護と必要なチェック\n\n以下はすべて、各プル要求がスタック ベースをターゲットとするかのように評価されます。直下の分岐は対象ではありません。\n\n| ルール             | 評価方法                                                                         |\n| --------------- | ---------------------------------------------------------------------------- |\n| 必須のレビュー         | スタック ベースに対して評価されます。                                                          |\n| 必須の状態チェック       | スタック ベースに対して評価されます。                                                          |\n| CODEOWNERS      | スタック ベースから評価されます。 より低い pull request の `CODEOWNERS` に対する変更が、その上のプル要求には影響しません。 |\n| コード スキャン ワークフロー | スタック ベースに対して評価されます。                                                          |\n\n## GitHub Actions\n\nGitHub アクション ワークフローは、スタック内の各プル要求がスタックのベースをターゲットにしているかのようにトリガーされます。\n`pull_request`を対象とする`main`イベントで実行するように構成されたワークフローは、一番下のプル要求だけでなく、スタック**内のすべての**プル要求に対して実行されるため、ワークフローの変更は必要ありません。\n\nスタックのベース ブランチなどのスタック メタデータは、 `github.event.pull_request.stack`を介してワークフロー式で使用できます。 このプロパティは、プル要求がスタックに属している場合にのみ存在します。\n\n冗長 CI の使用を減らすためのメタデータ フィールドとパターンの完全なセットについては、 [スタックされたプル要求に対する CI の最適化](/ja/enterprise-cloud@latest/pull-requests/how-tos/merge-and-close-pull-requests/optimizing-ci-for-stacked-pull-requests) を参照してください。\n\n## マージの要件\n\nスタック内のプル要求をマージする前に、次のすべてが当てはまる必要があります。\n\n* pull request は、必要なレビュー、必要な状態チェック、CODEOWNER 承認など、スタック ベースのすべてのブランチ保護要件を満たします。\n* スタック内**のその下にあるすべてのプル要求**も、これらの要件を満たしています。\n* スタックには、分岐間の **完全に線形の履歴** があります。\n\nたとえば、スタック `main ← PR1 ← PR2 ← PR3`では、PR #3 をマージするには、PR #1 と PR #2 もチェックに合格し、必要なレビューを行い、すべてのブランチ保護規則を満たす必要があります。\n\n## マージ メソッド\n\nスタックでは、3 つのマージ メソッドがすべてサポートされています。 いずれの場合も、pull requests は 1 つのアトミック操作として配置されます。\n\n* **マージ コミット** は、マージされるプル要求のグループ全体に対して 1 つのマージ コミットを作成し、各プル要求の完全なコミット履歴を保持します。\n* **スカッシュ** は、プル要求ごとに 1 つのクリーンでスカッシュされたコミットを作成します。 プル要求 `n` マージすると、ベース ブランチ `n` スカッシュされたコミットが作成されます。\n* **リベース** では、各プル要求からのコミットがベース ブランチに再生され、マージ コミットなしで線形履歴が作成されます。\n\n## マージ キューを使用したマージ\n\nスタックは、マージ キューを完全にサポートします。 スタック内のすべてのプル要求は、正しい順序でキューに追加されます。 プル要求がキューから削除または取り出された場合、スタック内のその上にあるすべてのプル要求も削除されます。\n\n> \\[!NOTE]\n> スタックを一緒に保持するために、マージ キューを使用すると、マージ グループは構成されている最大サイズを最大 50% 超える可能性があります。 スタックが大きすぎてそのバッファー内に収まらない場合、連続するマージ グループ間で自動的に分割されます。\n\n## 線形履歴\n\nスタック内のすべてのブランチ間の完全な線形履歴は、マージの厳密な要件です。 変更が下位分岐にプッシュされたとき、またはトランクが先に移動すると、スタックの線形履歴が失われる可能性があります。\n\n線形履歴を復元するには、連鎖リベースを実行します。\n\n* **CLI から** — `gh stack rebase`を実行し、 `gh stack push`を使用してプッシュします。\n* **GitHub Web サイト**で、マージ ボックスの \\[**Rebase stack**]\\(スタックのリベース) をクリックして、サーバー側のカスケード リベースをトリガーします。\n\n手順については、[スタックされたプル要求の管理](/ja/enterprise-cloud@latest/pull-requests/how-tos/create-pull-requests/managing-stacked-pull-requests#rebasing-your-stack) を参照してください。\n\n## 詳細については、次を参照してください。\n\n* [積み重ねられたプル要求を組織にロールアウトする](/ja/enterprise-cloud@latest/pull-requests/tutorials/roll-out-stacked-prs)"}