スタックされたプル要求

スタックは、同じリポジトリ内の一連のプル要求です。各プル要求は、その下のプル要求のブランチを対象とし、1 つのブランチ (通常はメイン ブランチ) に配置される順序付きチェーンを形成します。 1 つの大きなプル要求の代わりに、一連の小さなプル要求を取得します。 各プル要求には独自のフォーカスされた差分があるため、チームメイトは各レイヤーを個別に確認して承認できます。

スタック内のすべてのプル要求は、直接ターゲットとするブランチに関係なく、 スタックのベース (通常は main ) の規則に対して評価されます。 つまり、ミッドスタック プル要求は、下位プル要求と同じ標準に保持されます。

Stacked pull requests availability

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 に対する変更が、その上のプル要求には影響しません。
コード スキャン ワークフロー	スタック ベースに対して評価されます。

GitHub Actions

GitHub アクション ワークフローは、スタック内の各プル要求がスタックのベースをターゲットにしているかのようにトリガーされます。 mainを対象とするpull_requestイベントで実行するように構成されたワークフローは、一番下のプル要求だけでなく、スタック内のすべてのプル要求に対して実行されるため、ワークフローの変更は必要ありません。

スタックのベース ブランチなどのスタック メタデータは、 github.event.pull_request.stackを介してワークフロー式で使用できます。 このプロパティは、プル要求がスタックに属している場合にのみ存在します。

冗長 CI の使用を減らすためのメタデータ フィールドとパターンの完全なセットについては、 スタックされたプル要求に対する CI の最適化 を参照してください。

マージの要件

スタック内のプル要求をマージする前に、次のすべてが当てはまる必要があります。

• pull request は、必要なレビュー、必要な状態チェック、CODEOWNER 承認など、スタック ベースのすべてのブランチ保護要件を満たします。
• スタック内のその下にあるすべてのプル要求も、これらの要件を満たしています。
• スタックには、分岐間の 完全に線形の履歴 があります。

たとえば、スタック main ← PR1 ← PR2 ← PR3では、PR #3 をマージするには、PR #1 と PR #2 もチェックに合格し、必要なレビューを行い、すべてのブランチ保護規則を満たす必要があります。

マージ メソッド

スタックでは、3 つのマージ メソッドがすべてサポートされています。 いずれの場合も、pull requests は 1 つのアトミック操作として配置されます。

• マージ コミット は、マージされるプル要求のグループ全体に対して 1 つのマージ コミットを作成し、各プル要求の完全なコミット履歴を保持します。
• スカッシュ は、プル要求ごとに 1 つのクリーンでスカッシュされたコミットを作成します。 プル要求 n マージすると、ベース ブランチ n スカッシュされたコミットが作成されます。
• リベース では、各プル要求からのコミットがベース ブランチに再生され、マージ コミットなしで線形履歴が作成されます。

マージ キューを使用したマージ

スタックは、マージ キューを完全にサポートします。 スタック内のすべてのプル要求は、正しい順序でキューに追加されます。 プル要求がキューから削除または取り出された場合、スタック内のその上にあるすべてのプル要求も削除されます。

線形履歴

スタック内のすべてのブランチ間の完全な線形履歴は、マージの厳密な要件です。 変更が下位分岐にプッシュされたとき、またはトランクが先に移動すると、スタックの線形履歴が失われる可能性があります。

線形履歴を復元するには、連鎖リベースを実行します。

• CLI から — gh stack rebaseを実行し、 gh stack pushを使用してプッシュします。
• GitHub Web サイトで、マージ ボックスの [Rebase stack](スタックのリベース) をクリックして、サーバー側のカスケード リベースをトリガーします。

手順については、スタックされたプル要求の管理 を参照してください。

詳細については、次を参照してください。

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