# スタックされたプル要求の管理
GitHub CLIを使用して、スタックされたプル要求を再構築し、ブランチをリベースし、下位レイヤーに変更を加えます。
> \[!NOTE] この機能はパブリック プレビュー段階であり、変更される可能性があります。
スタックを反復処理するときは、多くの場合、下位レイヤーで変更を加えたり、線形履歴を保持するためにリベースしたり、分岐を再構築したりする必要があります。
GitHub CLIの`gh stack`拡張機能は、影響を受けるすべてのブランチを更新する連鎖操作でこれらのタスクを処理します。 「[Stacked pull requests CLI コマンド](/ja/pull-requests/reference/stacked-prs-cli-commands)」を参照してください。
## 下位レイヤーに変更を加える
最上位レイヤーで作業していて、スタック内の下位の部分を変更する必要がある場合は、現在のレイヤーで作業するのではなく、それが属するブランチで変更を加え、リベースします。
1. 変更が必要なブランチに移動します。
```shell copy
gh stack down
```
`gh stack checkout BRANCH-NAME`を使用して特定のブランチをチェックアウトすることもできます。
1. 変更を加えてコミットします。
```shell copy
git add .
git commit -m "helpful-commit-message"
```
2. 上記のブランチをリベースして、変更を取得します。
```shell copy
gh stack rebase --upstack
```
3. 更新されたブランチをプッシュし、作業していた場所に戻ります。
```shell copy
gh stack push
gh stack top
```
## スタックの再調整
マージする前に、スタックの分岐間に線形履歴が必要です。
`gh stack rebase`を実行すると、カスケードリベースが実行され、各ブランチは`main`から始まり、その下のブランチの上にリベースされるため、すべてのブランチはすべての下位レイヤーから最新の変更を取得します。
1. スタックをリベースします。 既定では、すべてのブランチが下から上にリベースされます。
```shell copy
gh stack rebase
```
リベースを制限するには、 `--downstack` を使用して、最下位レイヤーから現在のブランチまでリベースするか、現在のブランチから一番上までリベースする `--upstack` します。
2. 更新されたブランチをプッシュします。 これにより、 `--force-with-lease` を使用して、リベースされたブランチを安全に更新します。
```shell copy
gh stack push
```
リベースで競合が発生した場合、 `gh stack rebase` は停止し、競合するファイルが一覧表示されます。
* 影響を受けるファイル内のマーカーを解決し、 `git add`でステージングしてから、 `gh stack rebase --continue`実行します。
* 最初からやり直すには、 `gh stack rebase --abort` を実行して、すべてのブランチを事前リベース状態に復元します。
> \[!NOTE]
> プル要求からサーバー側のリベースをトリガーすることもできますが、それらのコミットは署名されません。 リポジトリで署名されたコミットが必要な場合は、 GitHub CLI からリベースして、コミットがローカル Git コミット署名の構成に従います。
### GitHub Web サイトからのリベイシング
スタックが線形でない場合は、マージ ボックスに **\[Rebase stack** ] ボタンが表示されます。 これを選択すると、次のようなサーバー側のカスケード リベースがトリガーされます。
1. `main`など、最新のトランクの上にスタック全体をリベースします。
2. スタックの下部から上に向かって動作し、そのベース ブランチの上に結合されていないすべてのブランチをリベースします。
3. リベースされた各ブランチを強制的にプッシュして、リモートを更新します。
リベースが完了すると、すべてのプル要求に更新されたブランチが反映され、CI チェックが再トリガーされます。
> \[!NOTE]
> サーバー側のリベースによって作成されたコミットは署名 **されません** 。 リポジトリで署名されたコミットが必要な場合は、`gh stack rebase`を使用してGitHub CLIからリベースし、コミットがローカル Git コミット署名の構成に従い、`gh stack push`でプッシュします。
## スタックの再構築
スタックの構成を変更することもできます。 たとえば、分岐を削除したり、分岐を結合したり、分岐を挿入したり、並べ替えたり、名前を変更したりする必要がある場合は、対話型コマンド `gh stack modify`を使用します。
`gh stack modify`を実行する前に、次のことを確認してください。
* アクティブなスタックがチェックアウトされています。
* 作業ツリーはクリーンです。
* リベースは進行中です。
* マージするキューに pull request がありません。
* コミット履歴は線形です。
1. ターミナル UI の変更を開きます。
```shell copy
gh stack modify
```
2. ブランチを選択し、操作をステージングします。 並べ替えと構造変更 (ドロップ、フォールド、挿入、名前変更) を同じセッションで混在させることはできません。
* `x` — ブランチとそのコミットを削除する
* `d` — 分岐をその下の分岐に折りたたむ
* `u` — 分岐をその上の分岐に折りたたむ
* `i`
/
`I` — カーソルの下または上に新しい分岐を挿入します。
* `r` — ブランチの名前を変更する
* Shift+↑ / Shift+↓ — 分岐を並べ替える
* `z` — 最後にステージングされた操作を元に戻す
3. 保存して段階的な変更を適用します。 保存するまで何も変更されません。
ctrl/cmd+を使用します。
適用中に競合が発生した場合は、それを解決して `gh stack modify --continue`実行するか、 `gh stack modify --abort` 実行して変更前の状態を復元します。
1. 更新されたブランチをプッシュし、 GitHubでスタックを再作成します。
```shell copy
gh stack submit
```
## GitHub Web サイトからのスタック解除
Web サイトからスタックをディゾルブする (例: 並べ替えや再構成) には、スタックの **\[Unstack]\(スタックの解除)** オプションを使用します。
スタックを解除すると **、開いている、下書き、閉じた** プル要求がスタックから削除されます。 それぞれが現在のベース ブランチを保持しますが、他のブランチにはリンクされなくなり、スタック マップとスタック マージの要件はそれらから消えます。
**マージされたプル要求とキューに登録されたプル要求はスタックに残ります。** プル要求がマージされるか、またはスタックの一部としてマージのキューに登録されると、スタックを解除することはできません。 スタックは、どのプル要求もマージされていないか、マージのためにキューに入れられている場合にのみ、完全にディゾルブされます。それ以外の場合は、それらのプル要求が引き続き保持されます。
スタックを分解せずに並べ替えたり再構築したりするには、代わりに `gh stack modify` コマンドを使用します。
[スタックの再構築を](#restructuring-a-stack)参照してください。
## マージ後のローカル環境の同期
スタックの下部にあるプル要求がマージされたら、1 つの同期コマンドを使用してローカル状態を更新します。 マージされたプル要求のローカル ブランチを同時に自動的に排除するには、 `--prune` オプションを追加します。
```shell copy
gh stack sync --prune
```
これにより、最新の変更がフェッチされ、トランクが迅速に転送され、残りのブランチがそれにリベースされ、更新されたブランチがプッシュされ、プル要求の状態が GitHubから同期されます。
### スタックに追加されたプル要求のプル GitHub
他のユーザーが GitHub上のスタックにプル要求を追加した場合、 `gh stack sync` は新しいブランチをフェッチし、リモートをミラーリングするようにローカル スタックに追加します。 このようなクリーンなリモート先行更新は自動的にプルダウンされるため、 `gh stack sync` は安全に自動化で実行できます。
### 分岐スタックの解決
ローカルスタックとリモートスタックは、どちらも他のブランチのクリーンな拡張でない場合(たとえば、ブランチをローカルに追加するときに、異なるプル要求が GitHub上の同じスタックに追加される場合など)に分岐します。 この場合、 `gh stack sync` は 2 つを自動的にマージできません。 対話型ターミナルでは、次の 3 つの選択肢があります。
* **リモート スタックを信頼のソースとして使用します。** ローカル スタックコンポジションをリモートに置き換え、不足しているブランチをプルします。 リモート スタックに含まれるものがないブランチを使用していた場合は、最も近い存続ブランチに移動されます。 これには、コミットされていない変更のないクリーンな作業ツリーが必要です。
* **GitHubのスタックを削除します。** GitHubのスタック オブジェクトを削除し、同期を停止します。pull request とローカル ブランチは変更されません。 `gh stack submit`を使用してスタックを再作成します。これによって、まだ送信していないブランチのプル要求も作成されます。 構造 `gh stack modify` 変更する場合は、最初に実行します。
* **キャンセル。** ブランチをプッシュしたり、プル要求を更新したりせずに同期を中止します。
CI などの非対話型ターミナルでは、分岐をプッシュしたりプル要求を更新したりせずに同期が中止されます。 スタックを解除して再作成して解決します。
## 次のステップ
* [スタックされたプル要求の確認](/ja/pull-requests/how-tos/review-pull-requests/reviewing-stacked-pull-requests)
* [スタックされたプル要求のマージ](/ja/pull-requests/how-tos/merge-and-close-pull-requests/merging-stacked-pull-requests)