テクノロジー · 実用ガイド
Git の fatal: bad object？削除前に ref・object・リポジトリ境界を証明する
ローカル作業を保全し、正確な ref と object を検査し、shallow/partial 境界を分類して、証拠が示す層だけを修復します。
`fatal: bad object` は一つの故障を示すメッセージではありません。Git が欠落 object を指す名前を解決した場合、無効な ref、意図的な shallow/partial 境界、別リポジトリ、実際の object 破損でも同じ表面エラーが起きます。
変更前に worktree とリポジトリ情報を保全し、正確な ref、object ID、型、到達可能性の境界を証明します。安全な修復は、証拠で壊れたと分かる最小の層だけを変え、回復経路を残します。
修復コマンドの前に作業を保存する
checkout、reset、gc、prune、repack、ref 削除の前に worktree とリポジトリ情報を保存します。status、ルート、Git ディレクトリ、remote、worktree、全 ref を記録し、資格情報だけを除きます。
大規模リポジトリでも未コミットファイル、HEAD、ref、reflog、shallow、alternates、partial 設定は残します。fresh clone は比較に使えますが、ローカル専用作業を確認するまで置換しません。
正確な名前を解決し正確な object を検査する
bad object の後の値をそのまま証拠にします。ref なら show-ref、for-each-ref、rev-parse で検証し、得た ID を cat-file -e と cat-file -t で存在と型に分けて確認します。
失敗したプロセスのリポジトリと worktree も確認します。エディタ、hook、service、CI は別のディレクトリや GIT_DIR を使うことがあるため、元の環境を再現します。
fsck の各行をデータ損失と決めつけない
保存したコピーで git fsck --full を実行します。missing、無効 ref、hash mismatch、壊れた object は重要です。一方 dangling は object が存在して通常 ref から到達できない状態で、回復材料かもしれません。
最初の有効なエラーを正確な ref または親 edge に戻します。不要なローカル ref 一つだけが欠落 object を指すなら、限定した update-ref -d は候補ですが、一括削除へ広げません。
意図した履歴境界と欠落データを分ける
.git/shallow、CI depth、partial filter、promisor remote、alternates、submodule を確認します。shallow root は意図した境界で、actions/checkout は既定で一 commit だけを取得します。
remote と必要履歴を確認してから deepen または正確な ref を fetch します。fetch-depth: 0 は全履歴を要求しますが、小さい深度や限定 fetch で十分な場合もあります。
最小の修復を選び終了条件を証明する
古い symbolic/remote ref は検証済み branch に向けるか、その一つだけを削除します。薄い clone は深化し、実際に欠落した到達可能 object は正常な clone、backup、別 object store から回復します。
元のコマンドを再試行し、ref、object、fsck を再確認します。未コミット作業を守り、fresh clone または backup が独立した回復経路を証明するまで損傷コピーを保持します。
