マージ済みリモートブランチを削除してmainだけにする手順

PRをマージしたはずなのに、GitHub上にはブランチがどんどん残っていく——そんな状態になったことはないでしょうか。

筆者も作業を続けているうちにリモートブランチが増え続け、「今どれが生きていて、どれが不要なのか」が分からなくなった経験があります。この記事では、マージ済みのリモートブランチを安全に削除して、ローカルもGitHubも main だけのシンプルな状態に整理する手順を1分で整理します。

今日の結論

• 理想の状態は「ローカルもGitHubも main だけ」
• 削除してよいのは、PRがMERGEDかつmainの祖先（ancestor）に取り込まれたブランチだけ
• 削除後は git fetch --prune でローカルの追跡参照も揃える

手順1｜削除してよいブランチか確認する

状況：GitHub上にマージ済みらしきブランチが残っている。

理由：見た目上はマージ済みに見えても、対象PRがMERGEDになっているか、そのブランチの変更がmainに実際に取り込まれている（mainの祖先＝ancestorになっている）かを確認しないまま削除すると、未反映の変更を消してしまうおそれがあります。

対策：GitHub上でPRのステータスがMERGEDになっていることを確認し、そのうえでブランチがmainの祖先に含まれているかをあわせて確認します。両方を満たしたブランチだけを削除対象とします。

手順2｜リモートブランチを削除する

状況：削除してよいブランチが確定した。

理由：GitHub画面から手動で削除することもできますが、コマンドで削除すると、複数ブランチの整理や記録が残しやすくなります。

対策：以下のコマンドで、対象のリモートブランチを削除します。

git push origin --delete <branch>

<branch> の部分には、削除対象のブランチ名を入れます。

なお、GitHubの「Automatically delete head branches」設定がオンになっているリポジトリでは、PRのマージ時にリモートブランチが自動削除されるため、この手順は不要です。

手順3｜ローカルの追跡参照を揃える

状況：リモート側のブランチは削除できたが、ローカルには origin/<branch> の参照がまだ残っている。

理由：リモートでブランチを削除しても、ローカル側の追跡参照（リモート追跡ブランチ）は自動的には消えません。そのままにしておくと、すでに存在しないブランチがローカルの一覧に残り続け、「迷子ブランチ」のような状態になります。

対策：以下のコマンドを実行し、ローカルの origin/* 追跡参照を最新の状態に揃えます。

git fetch --prune

これで、リモート側にすでに存在しないブランチの参照が、ローカルからも整理されます。

確認チェックリスト

• □ 対象PRがMERGEDになっていることを確認した
• □ ブランチがmainの祖先（ancestor）に取り込まれていることを確認した
• □ git push origin --delete <branch> でリモートブランチを削除した
• □ git fetch --prune でローカルの追跡参照を揃えた
• □ ローカル・GitHubの両方で main だけの状態になっている

まとめ・次に読む

マージ済みのリモートブランチは、「PRがMERGEDか」「mainの祖先に取り込まれているか」の2点さえ確認できれば、安全に削除できます。削除後に git fetch --prune を忘れずに実行しておくと、ローカル側に迷子の追跡参照が残らず、常にすっきりした状態を保てます。

AIツールを使った開発の全体像や、Git・GitHub・Vercel周りで初心者がつまずきやすいポイントについては、AI初心者がゼロからWebサイトを公開するまでにやったこと・詰まったこと全部まとめでまとめています。

次の1分Tipsでは、勝ち記事だけリライトに集中する理由を紹介します。

※ 本記事の内容は執筆時点（2026-07-19）のGit運用手順です。チーム開発のルールによっては、ブランチ削除の運用（自動削除設定・保護ブランチの扱いなど）が異なる場合があるため、リポジトリごとの運用ルールもあわせて確認してください。