# スタックされたプルリクエストの管理

GitHub CLIを使用して、スタックされたプル要求を再構築し、ブランチをリベースし、下位レイヤーに変更を加えます。

スタックに対して作業を進めるときは、多くの場合、下位レイヤーで変更を加えたり、線形履歴を保持するためにリベースしたり、そのブランチ群を再構成したりする必要があります。
`gh stack`のGitHub CLI拡張機能は、影響を受けるすべてのブランチを更新する連鎖操作でこれらのタスクを処理します。 「[スタックされたプルリクエストの CLI コマンド](/ja/enterprise-cloud@latest/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]
> サーバー側のリベースによって作成されたコミットは署名**されていません**。 リポジトリで署名付きコミットが必要な場合は、GitHub CLIから`gh stack rebase`でリベースしてコミットがローカル 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` — ブランチの名前を変更する
   * <kbd>Shift</kbd>+<kbd>↑</kbd> / <kbd>Shift</kbd>↓ — 分岐を並べ替える
   * `z` — 最後にステージされた操作を元に戻す

3. 保存してステージされた変更を適用します。 保存するまで何も変更されません。

<kbd>ctrl/cmd</kbd>+<kbd>s</kbd> を使用します。

適用中に競合が発生した場合は、それを解決して `gh stack modify --continue` を実行するか、`gh stack modify --abort` を実行して変更前の状態を復元します。

1. 更新されたブランチをプッシュし、GitHubでスタックを再作成してください。

   ```shell copy
   gh stack submit
   ```

## GitHub Web サイトからのスタック解除

たとえば並べ替えや再構成を行うためにWebサイト上のスタックを解除するには、スタックの**Unstack**オプションを使用します。

スタック解除すると、**開いている、下書き、閉じた**プル要求がスタックから削除されます。 それぞれが現在のベース ブランチを保持しますが、他のブランチにはリンクされなくなり、スタック マップとスタック マージの要件はそれらから消えます。

**マージされたプル要求とキューに登録されたプル要求はスタックに残ります。** プルリクエストがマージされるか、またはスタックの一部としてマージのキューに登録されると、そのスタックから外すことはできません。 スタックは、マージ済みまたはマージ待ちのプルリクエストが1つもない場合にのみ、完全に解消されます。それ以外の場合は、それらのプルリクエストを含んだまま残ります。

スタックを分解せずに並べ替えたり再構築したりするには、代わりに `gh stack modify` コマンドを使用します。
[スタックの再構築を](#restructuring-a-stack)参照してください。

## マージ後のローカル環境の同期

スタックの下部にあるプルリクエストがマージされたら、1 つの同期コマンドを使用してローカル状態を更新します。 マージされたプル リクエストのローカル ブランチを同時に自動的に削除するには、`--prune` オプションを追加します。

```shell copy
gh stack sync --prune
```

これにより、最新の変更がフェッチされ、トランクが fast-forward され、残りのブランチがそれにリベースされ、更新されたブランチがプッシュされ、プルリクエストの状態が 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/enterprise-cloud@latest/pull-requests/how-tos/review-pull-requests/reviewing-stacked-pull-requests)
* [スタックされたプルリクエストのマージ](/ja/enterprise-cloud@latest/pull-requests/how-tos/merge-and-close-pull-requests/merging-stacked-pull-requests)