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(日本語)