기술 · 실용 가이드

Git의 “object file is empty”? 삭제 전에 OID를 보존하세요

0바이트 loose object는 정리 대상이 아니라 저장소 증거입니다. 쓰기를 멈추고 전체 OID와 .git을 보존한 뒤 손상을 분류하고 정확한 복구 또는 작업 트리 구조를 선택하세요.

작성 Watch at Ease News · 4 분 읽기발행 2026. 10. 15. 오후 12:13 UTC

“object file … is empty”는 loose-object 경로가 있지만 Git이 유효한 객체를 읽지 못한다는 뜻입니다. 전체 OID와 저장소를 증거로 취급하고 빈 파일 일괄 삭제, reset --hard, .git 덮어쓰기로 시작하지 마세요.

Git 쓰기를 멈추고 working tree와 .git을 다른 저장소에 복사하며 정확한 OID를 기록한 뒤 읽기 중심으로 조사합니다. 복구는 객체 유형, 도달 가능성, remote·독립 clone·alternate·backup의 정상 사본 유무에 따라 달라집니다.

쓰기를 멈추고 증거 보존

editor, IDE Git 통합, background sync, maintenance를 멈춥니다. 전체 error, path, OID, 가능한 status와 crash, 전원, disk-full, filesystem 증상을 저장합니다.

working tree와 .git을 다른 저장소에 복사하고 0바이트 path를 전체 OID 이름으로 보존합니다. server bare repository는 쓰기를 중단하고 플랫폼 backup 절차를 따릅니다.

보존한 복사본에서 git fsck --full을 실행하고 reflog를 root에서 제외한 비교가 필요하면 --no-reflogs 출력도 저장합니다. missing, bad, dangling, unreachable을 구분합니다.

alternates, pack, refs, reflogs를 확인해 한 객체인지 여러 객체인지 판단합니다. 범위를 모른 채 gc, prune, reset --hard, 일괄 삭제를 실행하지 않습니다.

fsck 연결을 통해 blob, tree, commit, tag를 분류합니다. blob은 참조 tree와 git ls-tree로 path를 찾을 수 있지만 commit과 tree는 안전한 재구성이 더 어렵습니다.

독립 clone, remote, bundle, backup, alternate에서 전체 OID를 확인합니다. remote에 객체가 있고 로컬 전용 이력을 보존한 뒤에만 일반 fetch를 고려합니다.

신뢰할 수 있는 곳에 정확한 객체가 있으면 Git-aware 경로나 backup으로 복원하고 OID와 fsck를 다시 검증합니다. 다른 저장소의 .git 전체를 덮어쓰지 않습니다.

blob을 재구성할 수 있으면 복사본에서 git hash-object를 실행하고 OID가 완전히 같을 때만 씁니다. 아니면 작업 트리를 새 clone으로 구조하고 손상 저장소를 보존합니다.

도달 가능한 객체 오류가 사라지고 refs, history, 작업 변경이 남으며 새 독립 clone이 checkout될 때 복구가 끝납니다. dangling만 남는 것은 정상일 수 있습니다.

손상이 재발하거나 객체가 늘고 I/O, memory, power, filesystem 오류가 나타나면 저장소 수리를 멈추고 저장장치를 조사하며 검증 전까지 backup을 유지합니다.