# スタックプル要求のトラブルシューティング

リベースの競合、ブロックされたマージ、中断された操作、マージ キューの問題など、スタックされたプル要求に関する一般的な問題を解決します。

> \[!NOTE] この機能はパブリック プレビュー段階であり、変更される可能性があります。

この記事では、スタックプル要求を操作するときに発生する可能性がある一般的な問題とその解決方法について説明します。

## リベースによって競合が報告される

連鎖リベースで競合が発生すると、 `gh stack rebase` は停止し、競合するファイルが一覧表示されます。

競合を解決して続行するには:

1. 競合する各ファイルを開き、競合マーカー (`<<<<<<<`、 `=======`、 `>>>>>>>`) を解決します。

2. 解決されたファイルをステージングします。

   ```shell
   git add .
   ```

3. リベースを続行します。 残りの分岐は自動的にリベースされます。

   ```shell
   gh stack rebase --continue
   ```

競合が複雑すぎる場合、またはやり直したい場合は、リベースを中止して、すべてのブランチを事前リベース状態に復元します。

```shell
gh stack rebase --abort
```

## 競合が原因で同期が停止した

`gh stack sync`の実行中に競合が検出された場合、すべてのブランチは元の状態に復元されるため、部分的に更新されたままになります。 リベースを直接実行して対話形式で競合を解決し、更新されたブランチをプッシュします。

```shell
gh stack rebase
gh stack push
```

## 変更セッションが開始されない

`gh stack modify` にはクリーンな開始状態が必要です。 起動しない場合は、次の点を確認します。

* アクティブなスタックがチェックアウトされています。
* 作業ツリーはクリーンです。
* リベースは進行中です。
* マージするキューに pull request がありません。
* コミット履歴は線形です。 そうでない場合は、最初 `gh stack rebase` 実行します。

## 変更セッションが中断されました

たとえば、解決したくない競合やターミナルクラッシュによって `gh stack modify` が中断された場合は、開始前の状態にスタックを復元できます。 変更前のスナップショットは、復旧のためにローカルにキャッシュされます。

```shell
gh stack modify --abort
```

変更の適用中に競合が発生し、代わりに継続したい場合は、競合を解決し、 `git add`を使用してファイルをステージングしてから、 `gh stack modify --continue`実行します。

## pull request をマージできない

スタック内のプル要求は、その下のすべてのプル要求がすべてのマージ要件を満たし、スタックが完全に線形の履歴を持つ場合にのみマージできます。 マージがブロックされている場合は、次のことを確認します。

* pull request とその下のすべてのプル要求には、必要なレビューとチェックの受け渡しがあります。
* スタックには線形履歴があります。 変更が下位分岐にプッシュされた場合、またはトランクが先に移動した場合、履歴が線形でなくなる可能性があります。

線形履歴を復元するには、 `gh stack rebase` 実行してから `gh stack push`するか、マージ ボックスで \[ **スタックのリベース** ] をクリックします。 手順については、[スタックされたプル要求の管理](/ja/pull-requests/how-tos/create-pull-requests/managing-stacked-pull-requests) を参照してください。

## スタックの途中で停止したマージ

マージ前のチェックはマージの前に実行されますが、マージは失敗する可能性があります。 たとえば、予期しない競合や断続的な障害が原因です。 途中でエラーが発生した場合、マージはそのプル要求で停止します。

* マージに成功したその下のプル要求は、ベース ブランチに引き続き上陸します。
* 失敗したプル要求とその上のプル要求は開いたままです。

失敗したプル要求の問題を解決し、マージを再試行してスタックの残りの部分を配置します。

## マージ キューからプル要求が削除されました

スタックはマージ キューにまとめて保持されます。 プル要求がキューから削除または取り出された場合、スタック内のその上にあるすべてのプル要求も取り出されて削除されます。 基になる問題が解決されたら、スタックをキューに再追加します。

また、大規模なスタックは連続するマージ グループ間で分割される場合があります。マージ キューを使用すると、マージ グループは構成された最大サイズを最大 50% 超えてスタックを保持でき、収まらないプル要求は、完全なスタックが着陸するまで後続のグループで続行されます。

## スタックの途中でプル要求を閉じた

スタックの途中でプル要求を閉じると、その上にあるすべてのプル要求がマージできなくなります。 スタックリレーションシップは保持されるため、別のプル要求を開くか、スタックの構造を変更するには、まずスタックをディゾルブしてから再作成する必要があります。

GitHub Web サイトからスタックを解除することも、`gh stack modify`を使用してスタックを再構築することもできます。 スタックを解除すると、開いている、下書き、閉じられたプル要求のみが削除されます。マージされたプル要求とキューに登録されたプル要求はスタックに残ります。 「[スタックされたプル要求の管理](/ja/pull-requests/how-tos/create-pull-requests/managing-stacked-pull-requests#unstacking-from-the-github-website)」と「[スタックされたプル要求の管理](/ja/pull-requests/how-tos/create-pull-requests/managing-stacked-pull-requests#restructuring-a-stack)」を参照してください。

## リベース後にコミットが署名されない

プル要求からトリガーされたリベースは GitHubのサーバーで実行され、それらのコミットは署名 **されません** 。 リポジトリで署名されたコミットが必要な場合は、代わりに GitHub CLI からリベースします。

* `gh stack rebase`を実行すると、ローカル Git 操作が使用されるため、生成されたコミットはローカル Git コミット署名の構成に従います。
* 再basingした後、更新されたブランチを `gh stack push`でプッシュします。

## フォーク間でスタックを作成することはできません

スタック プル要求では、すべてのブランチが同じリポジトリに存在する必要があります。 クロスフォーク スタックはサポートされていません。