【Git入門】焦らず直せる git 5つの復旧パターン

まずは落ち着いて状況確認する

やらかしたと思った瞬間、いちばんやってはいけないのは「焦って何も分からないまま次に進もうとする」ことです。

何も分からないまま次に進んでも状況が良くなることはほとんどありません。

まずは状況確認をしましょう。

git status
git log --oneline -10

git status で作業ツリーとステージの状態、git log で直近の履歴を確認できます。

この2つで現状把握してから、次のパターンのどれに当てはまるか判断していきます。

5つのやらかし対処パターン

1. 直前のコミットを取り消したい

まだ push していないローカルのコミットを取り消したいケース。reset と amend を使い分けます。

# 変更内容を作業ツリーに残す
git reset --soft HEAD~1

# コミットとステージを取り消す
git reset --mixed HEAD~1

# 変更ごと丸ごと破棄する
git reset --hard HEAD~1

# 直前のコミット内容やメッセージを差し替え
git commit --amend

迷ったら --soft を選んでおくと安全です。

--hard は変更を跡形もなく消すので、本当に要らないと確信できる時だけがいいでしょう。

--amend はメッセージのタイプミスの修正に便利ですが、push 前に限定しましょう。

注意度: --soft/--mixed/--amend は低、--hard は高。

2. push 済みのコミットを打ち消したい

すでにリモートに push してしまった場合の鉄則は revert を使いましょう。

# 打ち消したいコミットのハッシュを指定
git revert abc1234
git push origin main

reset は履歴そのものを書き換えるため、他のメンバーがすでに pull していると履歴が食い違って修羅場になります。

一方 revert は「あのコミットを打ち消す」新しいコミットを追加するだけ。履歴は前に進むだけなので、他人に迷惑がかかりません。

push済みなら revert、と覚えるのが良いでしょう。

3. ブランチを間違えてコミットしてしまった

feature ブランチのつもりが main に居たまま、というよくあるやつです。

この場合は下記のような手順になります。

# 1. 今のコミットハッシュを確認
git log --oneline -3

# 2. 正しいブランチに移動（なければ作る）
git checkout -b feature/correct-name

# 3. さっきのコミットをこのブランチに持ってくる
git cherry-pick abc1234

# 4. 元のブランチに戻って余分なコミットを消す
git checkout main
git reset --hard origin/main

手順4は、リモートの main と同じ状態にローカルを揃える操作です。push 済みならこの手順は使わず、パターン2の revert を使ってください。

4. 消えたコミットやブランチを救出したい

「ブランチを消したら、やっぱり必要だった」「reset --hard で大事な変更が消えた」場合の手順です。

# HEAD の移動履歴を全部見る
git reflog

# 復元したいコミットを新しいブランチとして復活
git checkout -b rescue-branch abc1234

reflog は HEAD の移動履歴を記録していて、コミット・reset・checkout などがすべて残っています。

デフォルトで約90日間保持されるので、直近の「消えた」のほとんどはここから救出可能です。

git は簡単には消えません。

5. main に直接 push してしまった

緊急度は高いですが、慌てず対処すれば戻せます。

# 【安全策】revert で打ち消しコミットを新ブランチで作って PR
git checkout -b hotfix/revert-mistake
git revert abc1234
git push origin hotfix/revert-mistake

# 【最終手段】1人開発で誰も pull していないと確信できる時のみ
git reset --hard HEAD~1
git push --force-with-lease origin main

チーム開発なら迷わず安全策を使いましょう。

revert は履歴を壊さず、PR 経由でレビューも通せます。

force push は他メンバーの履歴と食い違いを起こすため、複数人が触っているブランチでは絶対NGになります。

--force ではなく --force-with-lease を使うと、リモートに知らない変更があった時に失敗してくれるので少し安全です。

事故を減らす3つの習慣

対処法を覚えるのも大事ですが、そもそも事故を減らせるとラクです。

• git status を癖にする: コミット前・push 前・ブランチ切り替え前に打つだけで、「今どこにいるんだっけ」の事故を防げます
• コミット前に git diff --staged で確認: ステージした変更が意図通りか確認できます。デバッグ用 print の混入事故が減ります
• main への直接作業を避ける: feature ブランチ運用にすれば、パターン5のような事故がそもそも起きません

まとめ

5つのパターンを振り返っておきます。

git の事故はほぼ対処できます。

まず git status と git log で状況確認しましょう。

あとは今日紹介した5パターンでなんとかなるはずです。

Git事故は未然に防ぐのが良いですが、どうしても起きる時があります。

事故を1回経験して自力で戻せた時、git への理解が一段深まります。

失敗を怖がらず、どんどん触っていきましょう。

記事を最後まで読んでいただきありがとうございました。また次の記事でお会いしましょう。