PRマージ後のブランチにpushしちゃった時の対処法

はじめに

GitとGitHubを使った開発で、こんな経験はありませんか？

1. feature/A ブランチをpushしてプルリクエスト（PR）を作成。
2. レビューが終わり、無事にPRがマージされる。
3. ローカルの feature/A ブランチで、ちょっとした修正や追加作業をして、再度push！
4. しかし、ターミナルにはエラーが表示されるか、pushできてもGitHub上で何も変化がない...。「あれ、なんで？」

PRがマージされたことで、リモート（GitHub上）のブランチはすでにその役目を終えて削除されていることがほとんどです。しかし、あなたのローカルPCにはまだそのブランチと、誰にも見られていない新しいコミットが残っています。

この記事では、そんな「宙に浮いてしまったコミット」を、安全かつ効率的に救出する方法を解説します。もう一度同じコードを書き直す必要はありません！

なぜこうなるの？PRとブランチのライフサイクル

この問題の根本原因は、GitHubの一般的なワークフローにあります。

1. PRはブランチに紐づく: プルリクエストは、特定のコミットではなく、ブランチ全体をマージ対象として扱います。
2. マージが完了するとブランチは不要に: feature/A の変更が develop や main などの基幹ブランチに取り込まれたら、feature/A というブランチは役目を終えます。
3. 自動でブランチを削除: 多くのプロジェクトでは、マージ後に不要なブランチが残り続けないよう、自動でリモートブランチを削除する設定にしています。

あなたの2回目のpushは、このすでに削除されたリモートブランチに向けられたものだったため、行き場をなくして失敗してしまったのです。

---

やってはいけないこと：作業のやり直し

「pushできなかったなら、もう一度新しいブランチで同じコードを書けばいいや」と考えるのは、最もやってはいけない対応です。

• 非効率: 同じ作業を二度行うことになります。
• ミスの元: 手作業でコードを写すと、必ずどこかでミスが生まれます。

Gitはあなたの行った変更（コミット）を絶対に失いません。あなたのローカルPC上に、そのコミットはまだ確実に存在しています。私たちに必要なのは、そのコミットを正しい場所へ「引っ越し」させることだけです。

---

git cherry-pickでコミットを救出する

ここで登場するのが、git cherry-pick という魔法のようなコマンドです。これは、他のブランチにある特定のコミットだけを、現在のブランチに「つまみ食い」するようにコピーしてこれるコマンドです。

ステップ1: 基幹ブランチを最新の状態にする

まずは、あなたのプロジェクトの基幹ブランチ（ここでは develop とします）を最新の状態にしましょう。これにより、マージされたあなたの最初のPRの内容もローカルに取り込まれます。

# developブランチに切り替える
git checkout develop

# リモートの最新の状態を取得する
git pull origin develop

💡 mainブランチが基幹の場合は、developをmainに読み替えてください。

ステップ2: 新しい作業ブランチを作成する

最新になった develop ブランチから、救出したいコミットのための新しいブランチを作成します。ブランチ名は、作業内容がわかるものにしましょう。

# 新しいブランチを作成し、そこに移動する
git checkout -b feature/add-hot-reload-setting

ステップ3: 救出したいコミットのIDを調べる

次に、古いブランチに残っている、救出対象のコミットID（ハッシュ値）を調べます。

# 古いブランチのコミット履歴を表示
git log feature/setup-local-environment

すると、以下のようなログが表示されます。

commit 4220d3f7a3575332d41308348179596b7961e669
Author: Hirotaka <[e-mail]>
Date:   Sun Aug 31 02:01:58 2025 -0700

    backendフォルダと、コンテナ内の/appフォルダを同期し、ホットリロードできる設定を追加

commit 9250c4cfa57fb8f34ced548e3bc29175fd50a110
Author: Hirotaka <[e-mail]>
Date:   Sun Aug 31 01:47:36 2025 -0700

    docker-compose.ymlファイルを作成し...

今回救出したいのは、マージされた後に追加した一番上のコミットです。この 4220d3f... という長い文字列がコミットIDです。

ステップ4: コミットを新しいブランチに適用する

いよいよ cherry-pick の出番です。ステップ2で作成した新しいブランチ (feature/add-hot-reload-setting) 上で、先ほど調べたコミットIDを指定します。

# コミットIDを指定して変更を適用する (IDは先頭の7文字程度でOK)
git cherry-pick 4220d3f

これで、あなたの変更が新しいブランチに無事コピーされました！

ステップ5: 新しいブランチをpushしてPRを作成する

最後に、この新しいブランチをGitHubにpushし、改めてプルリクエストを作成します。

git push origin feature/add-hot-reload-setting

これで、あなたの「失われたはずの作業」は、正しいフローに乗って再びレビューに出せる状態になりました。

---

まとめ：今後のための正しいGitフロー

今回の経験を次に活かすために、理想的なGitフローを覚えておきましょう。

1. 作業開始前: 必ず基幹ブランチ (develop など) に移動し、git pull で最新の状態にする。
2. ブランチ作成: git checkout -b <new-feature-branch> で新しい作業ブランチを作成する。
3. PRマージ後: マージされたローカルの作業ブランチは、もう不要です。混乱を避けるためにも削除しましょう (git branch -d <old-feature-branch>)。
4. 次の作業へ: 次の作業を始める際は、またステップ1に戻ります。

このサイクルを守ることで、「マージ済みブランチへのpush」という事故を防ぐことができます。

git cherry-pick は、今回のようなケース以外にも、特定の修正だけを別のブランチに適用したい場合など、様々な場面で役立つ強力なツールです。困ったときには、ぜひ思い出してみてください。