SJ blog
tools
S

信頼度ランク

S 公式ソース確認済み
A 成功実績多数・失敗例少数
B 賛否両論
C 動作未確認・セキュリティリスク高
Z 個人所感

Gitを使いこなす:知らないと損するコマンド5選

git bisect・git reflog・git worktree・git add -p・git log -S など、知っておくと開発効率が大幅に上がるGitコマンドを5個厳選して解説します。

一言結論

git bisectで二分探索しバグ混入コミットを特定し、git reflogで誤操作を取り消すスキルを持つだけで、Gitに起因する「詰まり」のほとんどを自力で解消できるようになる。

1. git log -S — 文字列が変更されたコミットを探す

「このコードはいつ誰が消したのか」を追跡するときに使う。grep では見つからない「過去の変更」まで掘り起こせる。

# "fetchUserData" という文字列が追加・削除されたコミットを探す
git log -S "fetchUserData" --source --all

# 変更内容も一緒に表示
git log -S "fetchUserData" -p

-G を使うと正規表現でマッチ。

2. git bisect — バグ混入コミットを二分探索

「前はちゃんと動いていたのに、いつから壊れた?」を高速に特定する。

git bisect start
git bisect bad                 # 現在のコミットは壊れている
git bisect good v1.2.0         # このタグ時点は正常だった

# git が中間コミットを自動的に checkout する
# 動作を確認して good か bad を入力
git bisect good   # または
git bisect bad

# 二分探索で log N 回繰り返すと原因コミットが特定される
git bisect reset  # 完了後に元に戻す

テストスクリプトを渡して完全自動化もできる。

git bisect run npm test

3. git worktree — 複数ブランチを同時に開く

ブランチを切り替えずに、別ブランチを別ディレクトリで開ける。作業中の変更を stash しなくてよい。

# hotfix/critical-bug ブランチを ../hotfix で開く
git worktree add ../hotfix hotfix/critical-bug

# 作業後に削除
git worktree remove ../hotfix

レビュー中に本番障害が発生した場合など、ブランチを行き来したいときに便利。

4. git add -p — 変更の一部だけをコミット

ファイルまるごとではなく、変更のハンク(差分の塊)を1つずつ確認してステージングできる。

git add -p
# y → このハンクをステージング
# n → スキップ
# s → ハンクをさらに分割
# e → 手動で編集

1つのファイルに「バグ修正」と「デバッグ用 console.log」が混在しているときに、コミットする部分だけを選べる。

5. git reflog — 消えたコミットを復元する

git reset --hard や誤ったブランチ削除で失ったと思ったコミットを復元できる。git log では見えない HEAD の移動履歴を保持している。

# HEADがたどってきた全履歴を表示
git reflog

# 出力例:
# abc1234 HEAD@{0}: reset: moving to HEAD~3
# def5678 HEAD@{1}: commit: ユーザー認証を実装
# ...

# 誤って reset した場合、元のコミットに戻す
git reset --hard HEAD@{1}

# または新しいブランチとして救出
git checkout -b rescue HEAD@{1}

reflog はローカルのみ(リモートには存在しない)。90日が過ぎると GC で削除されるため、気づいたら早めに復元する。


参考: Git 公式ドキュメント / Pro Git(日本語)