GitHubで削除したプルリクエストのブランチを復元する方法

GitHubでプルリクエスト後に削除したブランチをもう一度使いたい場合、閉じたプルリクエストのheadブランチであれば、対象PRの画面から「Restore branch」を選んで復元できます。

操作の流れは、リポジトリの「Pull requests」から「Closed」を開き、削除したブランチに対応するプルリクエストを選択して、画面下部の「Restore branch」を押すだけです。GitHub公式ドキュメントでも、閉じたプルリクエストのheadブランチをこの手順で復元できると案内されています。([GitHub Docs][1])

ただし、この機能はあらゆる削除データを復旧するものではありません。ローカルにしか存在しなかったブランチ、プルリクエストと関連付けられていないブランチ、削除済みリポジトリ、任意の失われたコミット履歴は、この手順の対象外です。

GitHubで削除したプルリクエストのブランチを復元する方法

復元を始める前に、対象が「Restore branch」で戻せるブランチか確認します。

確認する項目	Restore branchの対象	補足
閉じたプルリクエストのheadブランチ	対象	PR画面から復元する
プルリクエストと無関係なリモートブランチ	対象外	別の復旧方法を検討する
ローカルにしか存在しなかったブランチ	対象外	ローカルリポジトリ側で確認する
削除済みのリポジトリ	対象外	ブランチ復元とは別の問題
同じ名前のブランチを新しく作りたいだけ	復元は必須ではない	最新のベースブランチから新規作成する方法もある

ここでいうheadブランチとは、プルリクエストで変更を持ち込む側のブランチです。たとえば、feature/loginからmainへプルリクエストを作成した場合、復元対象はfeature/loginです。

GitHubで対象のリポジトリを開く

GitHubにログインし、削除したブランチが存在していたリポジトリを開きます。

Organizationやユーザー名が似ているリポジトリでは、別のリポジトリを開いていないか確認してください。フォーク元とフォーク先を取り違えると、目的のプルリクエストが見つからないことがあります。

Pull requestsからClosedを選ぶ

リポジトリ上部の「Pull requests」を選択します。

続いて、プルリクエスト一覧の「Closed」を選びます。復元機能は、閉じたプルリクエストに関連付けられていたheadブランチを対象としています。([GitHub Docs][1])

プルリクエストが多い場合は、次の情報を使って対象を絞り込みます。

• プルリクエストのタイトル
• プルリクエスト番号
• 作成者
• 閉じた時期
• headブランチ名
• 変更したファイル

ブランチ名だけで判断せず、プルリクエストの内容やコミットも確認すると、別のブランチを誤って復元する事故を防げます。

削除したブランチに対応するプルリクエストを開く

「Closed」の一覧から、復元したいブランチに対応するプルリクエストを開きます。

プルリクエストを開いたら、次の点を確認します。

• 表示されているheadブランチ名が目的のものか
• プルリクエストの変更内容が記憶している作業と一致するか
• 別のフォークやOrganizationのブランチではないか
• 復元後に必要となるコミットが含まれているか

特に、同じような名前のブランチを何度も作成しているリポジトリでは、ブランチ名だけでなくプルリクエスト番号と変更内容まで確認してください。

画面下部のRestore branchを選ぶ

プルリクエスト画面の下部まで移動し、「Restore branch」を選択します。

GitHub公式の手順でも、閉じたプルリクエストを開き、画面下部の「Restore branch」をクリックする流れが案内されています。([GitHub Docs][1])

操作後は、次のいずれかでブランチが復元されたことを確認します。

• プルリクエスト上でブランチが存在する状態になっている
• リポジトリのブランチ一覧に名前が表示される
• ローカルでgit fetchした後、リモート追跡ブランチを確認できる

「Restore branch」を押せたからといって、現在のmainやdevelopの内容まで自動的に取り込まれるわけではありません。復元と最新化は別の作業として扱います。

復元したブランチをローカルで使えるようにする

GitHub上でブランチを復元しても、ローカルリポジトリには復元前の情報が残っている場合があります。最初にリモートの最新情報を取得します。

以下では、復元したブランチ名を説明用にfeature/login-validationとしています。

git fetch origin

git fetchは、リモートリポジトリのブランチや関連オブジェクトを取得し、リモート追跡ブランチを更新するコマンドです。([Git][2])

ローカルに同名ブランチがない場合

ローカルブランチが存在しない場合は、復元されたリモートブランチを追跡するローカルブランチを作成します。

git switch --track origin/feature/login-validation

git switch --trackを使うと、リモート追跡ブランチを基にローカルブランチを作成し、上流ブランチの設定も行えます。([Git][3])

複数のリモートを登録している環境では、origin/を省略せず、どのリモートのブランチを使うのか明示したほうが安全です。

ローカルに同名ブランチが残っている場合

GitHub上のブランチを削除しても、ローカルブランチは残っていることがあります。この場合は、いきなり上書きや強制更新をせず、状態を確認します。

git fetch origin
git switch feature/login-validation
git status
git log --oneline --decorate --graph --all

ローカルブランチと復元されたリモートブランチに異なるコミットがある場合は、どちらを残すべきか確認してから統合します。

内容を確認しないままreset --hardやforce pushを実行すると、必要なローカル変更を失う可能性があります。復元直後は、まずコミット履歴と作業ツリーの状態を確認してください。

現在のベースブランチとの差分を確認する

削除から復元までの間に、mainやdevelopが更新されている可能性があります。復元したブランチで新しい作業を始める前に、現在のベースブランチとの差分を確認します。

ベースブランチがmainの場合は、次のように確認できます。

git fetch origin
git diff origin/main...HEAD

3点リーダーを使ったgit diff A...Bは、AとBの共通祖先を起点として、B側にある変更を確認する形式です。([Git][4])

少なくとも次の項目を確認してください。

確認項目	見るポイント
変更ファイル	古いPRの変更だけが表示されているか
ベースブランチの更新	競合しそうな修正が追加されていないか
依存関係	ライブラリや設定ファイルが更新されていないか
テスト	復元時点のコードでテストが通るか
CI	現在のワークフローでチェックが成功するか
ブランチ保護	現在のレビューやチェック要件を満たせるか

復元は、削除されたブランチを再び参照できる状態にする操作です。現在のベースブランチへ追従する処理ではありません。

同じブランチを再利用するか、新しいブランチを作るか

ブランチを復元できても、必ずそのまま再利用すべきとは限りません。作業の目的に応じて判断します。

状況	適した対応
閉じたPRの作業をそのまま再開したい	復元したブランチを継続利用する
レビュー指摘への修正を続けたい	復元後、差分を確認して作業する
古いコミットを調査したい	復元して履歴を確認する
古い作業と無関係な新機能を作る	最新のベースブランチから新しいブランチを作る
一部のコミットだけ再利用したい	新しいブランチへ必要なコミットだけ移すことを検討する
同じブランチ名だけ使いたい	復元ではなく新規作成も検討する

同じブランチを別の目的に使い回すと、古いプルリクエストとの関係が分かりにくくなります。チーム開発では、作業単位ごとに新しいブランチを作ったほうが、レビュー履歴や変更理由を追いやすくなります。

一方、閉じたプルリクエストの作業を再開する場合は、元のブランチを復元することで、コミットや議論との対応関係を保ちやすくなります。

Restore branchとRevertの違い

「Restore branch」と「Revert」は目的がまったく異なります。

操作	目的	結果
Restore branch	削除したheadブランチを戻す	ブランチを再び利用できる状態にする
Revert	マージ済みPRの変更を打ち消す	元のマージコミットを打ち消す新しいPRを作る

「ブランチを消してしまったので作業を再開したい」という場合に使うのはRestore branchです。

Revertは、すでにマージした変更に問題があり、その変更をベースブランチ上で取り消したい場合に使います。GitHubのRevert機能は、元のマージコミットを打ち消すための新しいプルリクエストを作成します。競合が発生する場合や、GitHub上でマージしていない場合は、個別のコミットを取り消す対応が必要になることもあります。([GitHub Docs][5])

ブランチを復元したいだけなのにRevertを選ぶと、目的とは異なる変更が作成されるため注意してください。

Restore branchが表示されないときの確認点

対象のプルリクエストを開いても「Restore branch」が表示されない場合は、次の順番で確認します。

Closedのプルリクエストを開いているか

GitHub公式の復元手順は、閉じたプルリクエストのheadブランチを対象としています。まず「Pull requests」の「Closed」から対象PRを開いているか確認してください。([GitHub Docs][1])

復元したいブランチがheadブランチか

ベースブランチではなく、変更を持ち込んだ側のheadブランチが復元対象です。

たとえば、次のプルリクエストではfeature/searchがheadブランチです。

feature/search → main

mainを復元する操作ではありません。

正しいプルリクエストを開いているか

同じブランチ名を過去に複数回使っていると、別のプルリクエストを開いている可能性があります。

プルリクエスト番号、作成者、コミット、変更ファイルを照合してください。

リポジトリの操作権限があるか

必要な操作権限がない場合、ブランチ関連のボタンが利用できないことがあります。

権限が不足している可能性があるときは、リポジトリ管理者に次の情報を添えて確認します。

• リポジトリ名
• 対象のプルリクエスト番号
• 復元したいブランチ名
• Restore branchが表示されないこと
• 作業を再開する目的

ローカルブランチが残っていないか

GitHub上で復元できなくても、自分やチームメンバーのローカル環境にブランチが残っている場合があります。

ローカルブランチが残っており、内容を確認できた場合は、必要な権限のもとでリモートへ再作成できます。

git switch feature/login-validation
git push -u origin feature/login-validation

git push origin <branch>は、ローカルブランチの参照と必要なオブジェクトをリモートリポジトリへ送信し、リモート側のブランチを更新または作成します。([Git][6])

ただし、同名のリモートブランチがすでに存在する場合は、その内容を確認してください。エラーを回避するためだけにforce pushを使用するのは避けます。

リポジトリ自体が利用できる状態か

Restore branchは、プルリクエストに関連付けられたブランチを復元する機能です。削除済みリポジトリそのものの回復を保証する機能ではありません。

リポジトリへアクセスできない場合や、リポジトリ自体が削除されている場合は、Organization管理者やリポジトリ所有者への確認が必要です。

ローカル専用ブランチの削除は別の復旧作業になる

削除したブランチが一度もGitHubへpushされておらず、プルリクエストも作成していない場合は、Restore branchを利用できません。

この場合は、ローカルリポジトリにコミットが残っているかを調査します。別ブランチから参照されているコミット、タグ、リモート追跡ブランチ、ほかの開発者のクローンなどが手掛かりになることがあります。

重要なのは、GitHubのRestore branchを「Git全体のデータ復旧機能」と考えないことです。

復元対象は、あくまで閉じたプルリクエストに関連付けられていたheadブランチです。対象外のブランチでは、ローカルリポジトリやバックアップを含めた別の調査が必要になります。

削除したブランチを復元した後の進め方

プルリクエスト後に削除したブランチをもう一度使う場合は、次の順番で進めると安全です。

1. 「Pull requests」から「Closed」を開く
2. 削除したブランチに対応するプルリクエストを特定する
3. headブランチ名と変更内容を確認する
4. 画面下部の「Restore branch」を選ぶ
5. ローカルでgit fetch originを実行する
6. 復元したブランチへ切り替える
7. 現在のベースブランチとの差分を確認する
8. 同じブランチを継続するか、新しいブランチを作るか判断する
9. テストやCIを確認してから新しい変更を加える

最初に行うべきことは、削除したブランチに対応するプルリクエストを「Closed」から探すことです。「Restore branch」が利用できた場合も、復元直後の状態を最新と決めつけず、現在のベースブランチとの差分を確認してから作業を再開してください。
[1]: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/deleting-and-restoring-branches-in-a-pull-request “Deleting and restoring branches in a pull request – GitHub Docs”
[2]: https://git-scm.com/docs/git-fetch “Git – git-fetch Documentation”
[3]: https://git-scm.com/docs/git-switch “Git – git-switch Documentation”
[4]: https://git-scm.com/docs/git-diff “Git – git-diff Documentation”
[5]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/reverting-a-pull-request “Reverting a pull request – GitHub Docs”
[6]: https://git-scm.com/docs/git-push “Git – git-push Documentation”