テクノロジー · 実用ガイド
Git の「pathspec did not match」は、まず引数の種類を特定する
失敗した引数がローカルブランチ、リモートブランチ、コミット、追跡済みパスのどれかを証明してから操作します。
「pathspec did not match any file(s) known to git」というメッセージだけでは、ブランチ、コミット、追跡済みパスのどれを意図したか分かりません。まず元のコマンドとリポジトリ状態を保存します。
このガイドは fetch、ブランチ作成、restore、reset、clean より前に、ref、オブジェクト、インデックス、tree を読み取り専用で確認します。ルートや対象が不明なら停止します。
リポジトリと元のコマンドを固定する
コマンド全体、エラー、作業ディレクトリ、綴り、引用符を保存します。ref やファイルを変える前に git rev-parse --show-toplevel、git status --short --branch、git remote -v、git --version を記録します。
git reset --hard、git clean、広い fetch、推測によるブランチ作成から始めないでください。証拠を消したり、意図を解決せずエラーだけ隠したりします。
引数が何を表すはずか決める
引数の想定種類を一つ書きます。既存ローカル、リモート、新規、コミットまたはタグ、追跡済みパスです。checkout は複数モードを持ち、refs、index、tree、-- で意味が変わります。
これは仮説であり修正ではありません。ブランチ風の名前は存在を、ファイル風の名前は追跡を、短いハッシュはローカルオブジェクトを証明しません。
ローカルとリモートのブランチを証明する
ローカルは git show-ref --verify refs/heads/NAME と git branch --all --no-color で確認します。リモートは git ls-remote --heads REMOTE NAME で変更せず照会し、状態を記録します。
リモートだけならその ref を正確に fetch して追跡ブランチを作ります。新規なら START を証明後に git switch -c NAME START を使います。作成を診断の代用にしません。
checkout 前にコミットやタグを証明する
git rev-parse --verify --end-of-options ARG^{commit} で現在のオブジェクトデータベースにあるコミットか確認します。失敗はローカルで解決不能という意味だけで、どの remote にあるかは示しません。
fetch 前に remote ref、tag、PR ref、submodule 記録、別リポジトリなど出所を特定します。最小の確認済み ref だけ取得します。
インデックスまたは別の tree でパスを証明する
git ls-files --error-unmatch -- PATH で index を変更せず確認します。別の tree は git ls-tree -r --name-only TREE -- PATH で調べ、大小文字や区切り、相対表記、shell 展開を確認します。
パスを意図するなら git restore --source=TREE -- PATH のように -- を置きます。古い手順では git checkout TREE -- PATH を使い、パス解釈を固定します。
証拠を一つの限定操作へ結び付ける
既存ローカルへ切替、新規は確認済み起点から作成、リモートだけなら正確に取得して追跡、コミットは意図した時だけ detached checkout、追跡済みパスは -- 付きで復元します。
どこにもなければ、文書、チケット、CI 変数、スクリプトなど名前の出所へ戻ります。不在が結論です。submodule、sparse checkout、shallow clone は別に調べます。
結果を検証しロールバック証拠を残す
修正した明示コマンドを実行し、git status --short --branch、git rev-parse --verify HEAD、必要な branch または path の証拠を再確認します。
作成 ref、取得 ref、復元パス、以前の HEAD、コマンドを記録します。固有作業がないと証明してから誤作成ブランチを削除し、確認済み tree からだけ復元します。
