コミットが見当たらないときは？git reflogでローカルの移動記録を読む

ブランチを動かしたあと、さっきのコミットがlogに見えない。すぐにresetを繰り返す前に、ローカルに残る参照の移動記録を読んでみよう。

この記事はGitのreflogを読む練習。既存のリポジトリではなく、一時的な練習フォルダーだけで進める。作業中の変更を持つ本番・共有チェックアウトでは、そのまま試さないでね。

logとreflogの違い

git logは、指定したコミットから親へたどる履歴を見る。一方reflogは、そのローカルリポジトリでHEADやブランチなどの参照が動いた記録。

reflogには、ブランチの切り替えやコミットなどの移動が残ることがある。リモートへpushすれば自分のreflog全体も相手へ送られる、という仕組みではないよ。

練習で、直前の移動を見る

空の場所で実行する例。利用者名とメールは、この練習リポジトリだけに設定する。

mkdir reflog-practice
cd reflog-practice
git init -q
git config user.name Practice
git config user.email practice@example.com
printf 'one\n' > note.txt
git add note.txt
git commit -qm first
printf 'two\n' >> note.txt
git commit -qam second
git switch --detach HEAD~1
git reflog -3

最後にfirstへ移動しても、reflogにはsecondからの移動が残る。この順序で実行した場合、git show HEAD@{1}:note.txt ではoneとtwoの二行を読める。ここまでを一時リポジトリで確認しているよ。

見つけたら、まず別名で残す

HEAD@{1}の意味は、その後の操作で変わる。実際の記録を確認し、目的のコミットのハッシュを控えよう。内容をgit showで読んだあと、必要なら git branch recovered <確認したハッシュ> のように、新しい名前で参照を作る方法がある。

この例は作業中のブランチをresetする方法ではない。既存のrecoveredがないことも確認し、必要なコミットかを読んでから操作する。

バックアップの代わりにはならない

reflogには有効期限があり、到達できないオブジェクトの削除も関係する。ディスク故障や、別の環境への引き継ぎまで守る仕組みではないよ。作業内容をいつでも必ず戻せるとは考えず、通常のコミット・push・バックアップも分けて用意しよう。

内容だけ読む基本はgit showで過去のファイルを読むへ。

参照した公式資料

• Git公式リポジトリ：git-reflog

確認日：2026年10月24日。