기술 · 실용 가이드
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 설정은 보존합니다. 새 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 object, 잘못된 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로 옮기거나 그 ref 하나만 삭제합니다. 얕은 clone은 깊게 만들고 실제 누락된 도달 object는 정상 clone, backup 또는 다른 object store에서 복구합니다.
원래 명령을 다시 실행하고 ref, object, fsck 해석을 재검사합니다. 미커밋 작업을 확인하고 새 clone이나 backup이 독립 복구 경로를 증명할 때까지 손상 사본을 보관합니다.
