gh-stackなるものが来るかもしれない

[Goryudyuma]

https://github.github.com/gh-stack/

もしきたら、diff-pr-managementも対応したほうが面白いかもしれない

[massongit]

まずgh-stackを普通に使ってみて、良さげってなったら対応させるのもありかもしれない。

[Goryudyuma]

2026-09-10時点の調査結果です。REST APIによるstack対応は技術的に可能ですが、複数formatterが同じ元PRに独立した修正PRを作る使い方を考えると、自動stack化はいったん見送るのがよさそうです。修正PRは独立させたまま、利用者が使っている既存stackとの共存・保護を検討する方針を提案します。

GitHubのnative stacked pull requestsは2026-07-30にpublic previewが始まっています。リリース告知

同じPRを複数stackに所属させられるか

現行の公式CLIには「one-stack constraint」があり、別stackに所属済みのPRを追加しようとすると、先にunstackするよう求めて拒否します。拒否時に追加APIを呼ばないことを確認するテストもあります。

• 公式CLIの実装
• 別stack所属PRの追加を拒否するテスト

したがって、[元PR, format修正PR] と [元PR, lint修正PR] を別々のstackとして共存させる設計にはできません。CLIの「branch belongs to multiple stacks」という記述はローカルのブランチ・共通trunkの扱いであり、同じリモートPRの複数所属とは別です。

API連携の方法と制約

Stacks REST APIには次の操作があります。

用途	API
PRが所属するstackを取得	GET /repos/{owner}/{repo}/stacks?pull_request={PR番号}
stackを作成	POST /repos/{owner}/{repo}/stacks、本文に {"pull_requests":[元PR番号,修正PR番号]}
既存stackの一番上へ追加	POST /repos/{owner}/{repo}/stacks/{stack_number}/add

作成・追加に必要な権限は pull-requests: write です。追加APIは一番上への追加に対応し、最初に追加するPRのbaseが既存stackの最上位PRのheadと一致する必要があります。途中のPRへの修正を挿入する場合は、上位PRのbaseや履歴の組み替えが必要になります。

PRのRESTレスポンスやWebhookにも stack 情報があります。GraphQLのstack関連フィールドは読み取り専用なので、登録処理はREST APIを使います。API・Webhook仕様
また、stack内のブランチは同一リポジトリに存在する必要があり、cross-fork stackは非対応です。stackの要件

現在のdiff-pr-managementとの相性

現状でもブランチ関係は main ← 元PRのブランチ ← 修正ブランチ になっており、修正PRのbaseには元PRのheadを指定しています。PR作成処理

ただし、stack登録後は次の違いが生じます。

観点	現在	native stack化した場合
修正PRのマージ	修正を元PRのブランチへ取り込む	元PRを含む下位の未マージPRも、mainなどのstackのtrunkへまとめて取り込む
CI	修正が必要なら元PRのCIをデフォルトで失敗させる	下位PRの必須チェックも通る必要がある
元PRだけ先にマージ	修正PRを自動closeし、修正ブランチを削除する	GitHubは残った修正PRをtrunkへ付け替えて開いたままにする

stackでは下から順にマージし、選んだPRの下にある未マージPRも一緒に取り込まれます。修正PRだけを元PRのブランチへ先にマージする、現在の操作とは意味が変わります。マージ仕様

特に、現在の exit-failure: true による失敗を必須チェックにしている場合、「修正PRをマージしたいが、元PRのフォーマット失敗でstackをマージできない」状態になります。 現在の失敗処理
このActionを exit-failure: false にしても、別の必須フォーマットチェックが元PRで失敗する場合は解消しないため、CIの運用も検討が必要です。生成するPR本文・図も現在のマージ手順を説明しているので、stackモードでは変更が必要です。

複数formatterが修正PRを作る場合

たとえばJSのfmtとGoのfmtを別々に実行し、異なる branch-name-prefix で修正PRを作る場合、自然な関係は次のようになります。

元PRのブランチ
├─ JS fmt修正PR（base: 元PRのブランチ）
└─ Go fmt修正PR（base: 元PRのブランチ）

この例ではJS修正とGo修正は互いに依存せず、どちらも元PRに対する独立した修正です。一つのnative stackにまとめるには、たとえば main ← 元PR ← JS修正 ← Go修正 という順序を付け、Go修正をJS修正のブランチの上に作り直す必要があります。

この直列化によって、本来不要だった調整が生じます。

• Go修正の生成が、JS修正のブランチや更新タイミングに依存する。
• JS修正が更新されたり不要になったりすると、Go修正のbaseや履歴の調整も必要になる。
• 別々のworkflowで動くformatter同士に、実行順序や更新・close処理の連携が必要になる。

一方、二つのstack [元PR, JS修正PR] と [元PR, Go修正PR] に分ける方法も、元PRの複数stack所属ができないため使えません。最初に作られた修正PRだけを元PRとstack化しても、後から別formatterの修正PRが作られる可能性があるため、「新規の2 PRだけstack化する」という条件だけでは問題を解消できません。

現在の構成なら、独立した修正をそれぞれ元PRへ取り込み、残った差分は各formatterの次のCIで再生成できます。formatterごとに修正PRを管理する現在の設計と合っています。native stackのマージ・必須チェックの制約も踏まえると、stackを自動作成する機能の追加はいったん見送り、修正PRを独立させておく方が適していると考えます。上記の作成・追加APIの調査結果は、将来再検討する場合の参考として残します。

既存stackとの共存・保護として検討する範囲

1. 修正PRをnative stackへ自動登録せず、各formatterが元PRのブランチをbaseとする通常の修正PRを作る方式を維持する。元PRが利用者のstackに所属している場合も、この方式を基本とする。
2. 既存stackの解体・移動・並べ替えや、利用者のPRのbase変更は行わない。
3. 元PR・既存修正PRの所属やbaseをforce pushの前に確認し、close専用経路にも確認を入れる。修正PRが利用者によってstackへ組み込まれたりbaseを変更されたりしていたら、更新・自動close・枝削除を継続しない保護を検討する。
4. 修正ブランチをbaseにする別PRの存在も確認し、上にPRが積まれたブランチを自動削除したり、履歴の前提をforce pushで崩したりしないようにする。
5. Actionが管理する修正PRを確実に識別し、「stack未所属」と「権限不足・API非対応・通信失敗などで確認できない」を区別する。確認できなかった状態を、安全に更新・削除できる根拠にしない。

この方針では、stack作成を前提としたCIやマージ手順の変更は行わず、既存stackを検出して保護する対応を中心に検討します。

現状はPR状態を調べる前に修正ブランチをforce pushし、更新・close対象は主に生成規則のhead名で識別しています。検索処理
stack所属を確認せずclose・枝削除するため、修正PRが手動でstackに組み込まれた場合や、その修正ブランチの上に別PRが積まれた場合に干渉し得ます。

本調査は公式ドキュメント、公式CLIのコード・mockテスト、このリポジトリの実装を読んだものです。実際のGitHubサーバーへのstack作成・重複所属の試行、および対応コードの実装は未実施です。