積み重ねられたプル要求を組織にロールアウトする

積み重ねられたプル要求を計画し、組織にロールアウトすることで、チームは既存のルールやチェックを損なうことなく、小規模でレビュー可能なレイヤーとして大きな変更を出荷できます。

この機能を使用できるユーザーについて

Enterprise and organization owners

この記事で

メモ

スタック プル要求は パブリック プレビュー であり、変更される可能性があります。

スタックプル要求を使用すると、開発者は大きな変更を互いに基づいて構築される小さなプル要求のチェーンに分割でき、各レイヤーの確認、マージ、出荷が容易になります。 積み上げプル要求により、開発者は柔軟に 1 つの作業を完了し、レビューが着陸するのを待たずに次の作業に直接移動できます。 これは、チームが大規模なリリースに取り組み、すべての変更が最後のリリースに基づいて構築される場合に一般的な作業が、その前に何が起きたかに自然に依存する場合に最も重要です。

このチュートリアルでは、積み重ねられたプル要求のために組織を準備する手順について説明します。ロールアウトに関する考慮事項の確認、ブランチ保護規則と CI とスタックの連携方法の理解、チームの開始について説明します。 スタックされたプル要求の基本的な理解については、 積み上げプル要求について を参照してください。

Prerequisites

チームが既にプル要求を使用している場合は、スタックプル要求を使用するように設定されています。 このチュートリアルのその他はすべて省略可能ですが、組織には次のものがあることを前提としています。

  • GitHub CLIをクリックします。 gh-stack 拡張機能がインストールされています。 CLI 拡張機能は、スタックを作成および管理するための最も包括的な方法です。
  • 既定のブランチ用に構成されたブランチ保護規則。
  • GitHub Actions 既定のブランチを対象とするプル要求で実行されるワークフロー。

Copilot は、スタックされたプル要求を使用する必要はありませんが、AI によって生成された変更をスタックするチームには推奨されます。 スタック プル要求は、提供されたエージェント スキルを使用して、Claude Code や Codex などの他の AI コーディング エージェントでも機能します。 「プル要求で AI によって生成されたコードをスタックする」を参照してください。

1. ロールアウトに関する考慮事項を確認する

チームにスタックプル要求を導入する前に、次の考慮事項を確認して、誰もが何を期待するかを把握してください。

スタックは線形である必要があり、フォークを含めることはできません

スタック内のすべてのプル要求は、同じリポジトリの一部であり、分岐の単一の線形チェーン上に構築されている必要があります。 分岐構造を持つスタック、またはフォークからのプル要求はサポートされていません。 チームが投稿のフォークに依存している場合は、現時点ではそれらの投稿をスタックの外部に保持することを計画してください。

スタックを並べ替えるには、 GitHub CLI

チームがスタック内のプル要求の順序を変更する必要がある場合は、gh stackGitHub CLI拡張機能でgh stack modifyを使用する必要があります。 GitHub Web サイトからスタックを並べ替える方法はありません。 CLI をローカルで使用しないチームは、スタック注文を事前に慎重に計画するか、このタスクの拡張機能をインストールする必要があります。

完了したスタックを拡張できない

スタック内のすべてのプル要求がマージされると、そのスタックは閉じられます。 チームが一番上に新しいブランチを追加し、 gh stack submit実行すると、CLI は同じベース ブランチで新しいスタックを開始します。 スタックの作業を継続するチームは、すべての作業が完了するまでスタックを開いたままにしておく必要があります。

2. ブランチ保護規則と CI がスタックとどのように連携するかを理解する

スタックプル要求は、他のプル要求と同じ方法で既存のルールを適用するように設計されていますが、スタック内のすべてのプル要求が予想とは少し異なる方法で評価されるため、方法を理解する価値があります。

一番下のプル要求だけでなく、スタック内のすべてのプル要求は、直接対象となるブランチではなく、 スタックのベース (通常は main) に対して評価されます。 これは次のことを意味します。

  • 必要なレビュー、必要な状態チェック、および CODEOWNERS はすべて、スタック内のすべてのプル要求に対してスタックのベース ブランチに対して適用されます。
  • mainを対象とするpull_request イベントをトリガーするGitHub Actions ワークフローは、スタック内のすべてのプル要求に対して実行されるため、既存の CI 構成を変更する必要はありません。
  • スタック メタデータは、 github.event.pull_request.stackを使用してワークフロー式で使用できます。これは、スタックされたプル要求専用にワークフローの動作をカスタマイズする場合です。 ワークフローはスタック内のプル要求ごとに 1 回実行されるため、チームはこのメタデータを使用して、冗長な実行でコストのかかるジョブをスキップし、CI の使用量を減らすことができます。 詳細については、「スタックされたプル要求に対する CI の最適化」を参照してください。

必要に応じて、標準のルールセットと必要なチェックが実施されたリポジトリに対して小さなテスト スタックを開き、次の点を確認することで、これが実際に動作することを確認できます。

  1. レビューと状態チェックは、一番下だけでなく、スタック内のすべてのプル要求で必要です。
  2. CI ワークフローは、スタック内のすべてのプル要求で実行されます。
  3. マージは、マージするスタック内のプル要求とその下にあるすべてのものが要件を満たすまでブロックされます。

ルールと要件の完全な一覧については、 スタックされたプル要求 を参照してください。

3. チームを開始する

ロールアウトの考慮事項を確認し、ルールと CI がスタックでどのように機能するかを理解したら、チームを スタックされたプル要求 🥞 にポイントします。これにより、スタックされたプル要求の作成、レビュー、マージを開始するために必要なすべてのものがまとめられます。

4. プログラムツールを更新する

組織がスタックプル要求を採用する場合は、プログラムによってプル要求を作成、マージ、または追跡する社内ツール、ボット、またはダッシュボードを確認し、スタックを考慮するように更新します。

重要

スタック プル要求をマージするには、Stacks API が必要です。 従来の pull request マージ エンドポイントはスタックをマージできません。 社内ツールや ChatOps ボットなどを使用して、組織がプログラムによってプル要求をマージする場合は、スタックされたプル要求をロールアウトする前に、そのツールを更新して Stacks API を呼び出します。

また、ダッシュボード、ボット、内部ツール全体など、プログラムによってスタック アクティビティを追跡することもできます。

  • REST API: API によって返されるすべてのプル要求には、スタックに属している場合に stack オブジェクトが含まれます。スタックの数、サイズ、その中でのプル要求の位置、およびスタックのベース ブランチが表示されます。 専用 Stacks API (GET /repos/{owner}/{repo}/stacks) には、リポジトリ内のすべてのスタック、または特定のプル要求を含む特定のスタックも一覧表示されます。 「REST API と GraphQL API のスタック プル要求」を参照してください。
  • Webhook: pull_request webhook ペイロードには、プル要求がスタックに属するたびに同じ stack オブジェクトが含まれます。 プル要求が最初にスタックに追加されると、専用の stacked アクションが発生するため、スタックが形成された瞬間に対応できます。

どちらの場合も、 stack フィールドはスタンドアロンのプル要求に対して null されるため、スタックを予期しない既存の統合は引き続き変更されずに機能します。