スタックは、同じリポジトリ内の一連のプル要求です。各プル要求は、その下のプル要求のブランチを対象とし、1 つのブランチ (通常はメイン ブランチ) に配置される順序付きチェーンを形成します。 1 つの大きなプル要求の代わりに、一連の小さなプル要求を取得します。 各プル要求には独自のフォーカスされた差分があるため、チームメイトは各レイヤーを個別に確認して承認できます。
スタック内のすべてのプルリクエストは、直接ターゲットとするブランチに関係なく、スタックのベース (通常は main ) に対するルールに基づいて評価されます。 つまり、ミッドスタック プル リクエストは、下位のプル リクエストと同じ基準で扱われます。
メモ
- スタック プル要求では、すべてのブランチが同じリポジトリに存在する必要があります。 クロスフォーク スタックはサポートされていません。
- GitHub Desktopでは、スタックプル要求はサポートされていません。
スタックされたプル リクエストの可用性
gh stack
GitHub CLI拡張機能は、ローカル開発ワークフローを処理します。 正しい依存関係の順序で分岐を作成および追跡し、ブランチのリベースを維持し、ブランチをプッシュし、プルリクエストを作成してリンクし、レイヤー間を移動します。
GitHub CLI は必須ではありません。 基になる Git 操作は標準であり、代わりに GitHub Web サイトからスタックを作成できます。
Jujutsu や Sapling などの他のツールを使用してローカル ブランチを管理およびプッシュする場合でも、GitHub CLI または GitHub Web サイトを使用して、それらのブランチからプルリクエストのスタックを開くことができます。 「他のツールで積み上げプル リクエストを使用する」を参照してください。
スタックされたプルリクエストのメインブランチ
スタックの トランク は、下位プルリクエストのベース ブランチです。 スタック内の残りのすべてのプルリクエストは、その上に構築されます。 トランクは既定でリポジトリの既定のブランチ（main など）になりますが、リリース ブランチや有効期間の長い機能ブランチなど、任意のブランチにすることができます。
トランクを設定するには:
- GitHub CLIから、
--base BRANCHオプションをgh stack initコマンドに渡します (たとえば、gh stack init --base release auth-layer)。 - GitHub Web サイトから、トランクにしたい任意のブランチに対する下側のプル リクエストを作成します。 スタックの残りの部分は、その上に構築されます。
ブランチ保護規則、必要なチェック、CI はすべて、既定のブランチだけでなく、スタックが対象とする任意のトランクに対して評価されます。
ブランチ保護と必要なチェック
以下はすべて、各プル リクエストがスタック ベースを対象としているものとして評価されます。直下のブランチは対象ではありません。
| ルール | 評価方法 |
|---|---|
| 必須のレビュー | スタック ベースに対して評価されます。 |
| 必須の状態チェック | スタックベースに対して評価されます。 |
| CODEOWNERS | スタックベースから評価。 より下位の pull request での CODEOWNERS の変更は、その上位の pull request には影響しません。 |
| コードスキャン ワークフロー | スタックベースを基準に評価されます。 |
GitHub Actions
GitHub アクション ワークフローは、スタック内の各プル要求がスタックのベースをターゲットにしているかのようにトリガーされます。
pull_requestを対象とするmainイベントで実行するように構成されたワークフローは、一番下のプル要求だけでなく、スタック内のすべてのプル要求に対して実行されるため、ワークフローの変更は必要ありません。
スタックのベース ブランチなどのスタック メタデータは、 github.event.pull_request.stackを介してワークフロー式で使用できます。 このプロパティは、プル要求がスタックに属している場合にのみ存在します。
冗長 CI の使用を減らすためのメタデータ フィールドとパターンの完全なセットについては、 スタックされたプル要求に対する CI の最適化 を参照してください。
リベイシング
リベースが使用可能または必要な場合、マージ ボックスには Rebase stack ボタンが表示され、これを示します。 たとえば、プル リクエストに対する変更によってスタックが非線形になる場合に発生する可能性があります。 一番下のプルリクエストがマージされると、リベースが自動的に行われ、通常は手動でリベースする必要はありません。
スタックがリベースされると、次のことが予想されます。
- スタックをリベースすると、署名付きコミットが生成されます。
- 差分が変更されない場合、スタックのリベースは新しいレビュー可能なコミットとしてカウントされません。 この状況では、新しいコミットがプッシュされたときに古いプル リクエストの承認を却下する規則が有効になっている場合でも、承認は保持されます。
マージの要件
スタック内のプルリクエストをマージする前に、次のすべてが当てはまる必要があります。
- pull request は、必要なレビュー、必要な状態チェック、CODEOWNER 承認など、スタック ベースのすべてのブランチ保護要件を満たします。
- スタック内でそれより下にあるすべてのプルリクエストも、これらの要件を満たしています。
- スタックには、分岐間の 完全に線形の履歴 があります。
たとえば、スタック main ← PR1 ← PR2 ← PR3では、PR #3 をマージするには、PR #1 と PR #2 もチェックに合格し、必要なレビューを受けており、すべてのブランチ保護規則を満たす必要があります。
メモ
スタックプルリクエストは バイパスルールを使用したマージをサポートしますが、この方法でマージできるのは一番下のプルリクエストだけです。 スタック全体をバイパス ルールを使用してマージすることはできません。 「リポジトリのルールセットの作成」を参照してください
マージ方法
スタックは、3 つのマージ メソッドすべてをサポートしています。 いずれの場合も、pull requests は 1 つのアトミック操作として反映されます。
- マージ コミット は、マージされるプル リクエストごとに 1 つのマージ コミットを作成し、各プル リクエストの完全なコミット履歴を保持します。
- スカッシュ は、プルリクエストごとに 1 つのクリーンでスカッシュされたコミットを作成します。 プル リクエストを
nマージすると、ベース ブランチ上にnスカッシュされたコミットが作成されます。 - リベース では、各プル要求からのコミットがベース ブランチに再生され、マージ コミットなしで線形履歴が作成されます。
マージ キューを使用したマージ
スタックは、マージ キューを完全にサポートします。 スタック内のすべてのプルリクエストは、正しい順序でキューに追加されます。 プルリクエストがキューから削除または除外された場合、スタック内のその上にあるすべてのプルリクエストも削除されます。
メモ
スタックを一緒に保持するために、マージキューでは、マージグループは構成されている最大サイズを最大 50% 超える可能性があります。 スタックが大きすぎてそのバッファー内に収まらない場合は、1 つの単位として次のマージ グループに自動的に配置されます。
線形履歴
スタック内のすべてのブランチ間の完全な線形履歴は、マージの厳密な要件です。 変更が下位分岐にプッシュされたとき、またはトランクが先に進むと、スタックの線形履歴が失われる可能性があります。
線形履歴を復元するには、カスケード リベースを実行します。
- CLI から —
gh stack rebaseを実行し、gh stack pushを使用してプッシュします。 - GitHub Web サイトから、マージ ボックスの [Rebase stack] をクリックして、サーバー側のカスケード リベースをトリガーします。
手順については、スタックされたプルリクエストの管理 を参照してください。