기술 · 실용 가이드

Git LFS가 파일이 포인터여야 했다고 하나요? 작업 사본을 잃지 않고 인덱스를 고치세요

먼저 파일을 보존하고 속성 규칙과 Git 객체의 불일치를 증명한 뒤 좁은 재정규화 또는 협업 이력 마이그레이션을 선택하고 새 clone으로 검증하세요.

작성 Watch at Ease News · 4 분 읽기발행 2026. 10. 19. 오전 12:42 UTC

이 경고는 보통 .gitattributes가 LFS를 요구하지만 커밋이나 인덱스가 전체 파일을 일반 Git blob으로 저장했음을 뜻합니다. clean 필터가 비교용 포인터를 만들기 때문에 reset 뒤에도 수정 표시가 돌아올 수 있습니다.

git reset --hard, .git/lfs 삭제, 강제 push부터 하지 마세요. 작업 바이트를 보존하고 규칙과 객체를 확인한 뒤 가장 좁은 범위를 고치고 원격 LFS 객체를 증명하세요.

1. Git 변경 전 바이트 보존

reset, checkout 또는 마이그레이션 전에 대상 파일을 저장소 밖으로 복사하거나 암호학적 해시를 기록하고 git status, 경로와 현재 브랜치도 보존하세요.

관련 없는 변경이 있으면 중단하세요. 깨끗한 브랜치나 일회용 clone에서 재정규화하고 보존 파일은 밖에 두는 편이 안전합니다.

git check-attr -a -- path로 중첩 .gitattributes와 대소문자 패턴을 포함한 실제 규칙을 찾고 작업 파일을 덮지 않은 채 인덱스나 HEAD 객체를 검사하세요.

실제 LFS 포인터는 version, OID, size를 가진 짧은 텍스트입니다. LFS 대상인데 HEAD가 전체 blob이면 작업 바이트 변화가 아니라 표현 불일치입니다.

현재 브랜치에서는 의도한 규칙을 명시하고 깨끗한 트리에서 git add --renormalize -- path를 실행한 뒤 staged diff를 읽으세요. 인덱스는 포인터가 되고 작업 파일은 실제 바이트를 유지해야 합니다.

검토한 규칙과 포인터 수정만 커밋하세요. 이 수정은 그 커밋 이후 해당 브랜치에 적용되므로 다른 브랜치는 별도로 처리합니다.

과거 커밋 변환이나 호스팅 이력 제한 때문에 필요할 때만 git lfs migrate를 쓰세요. 일회용 clone에서 --no-rewrite 또는 import --fixup과 정확한 refs를 시험하세요.

이력 마이그레이션은 커밋 ID를 바꾸고 강제 push와 재 clone을 요구할 수 있습니다. refs를 백업하고 전환을 협의하며 공유 원격에서 범위를 탐색하지 마세요.

선택 범위에 git lfs fsck --pointers를 실행하고 git lfs fsck로 로컬 객체를 검사하세요. push 전에 git lfs ls-files와 포인터 OID를 확인합니다.

Git ref뿐 아니라 LFS 객체도 올려야 합니다. Git push 성공이나 clean status는 대형 객체가 원격 저장소에 도착했다는 증거가 아닙니다. 해시를 보존하세요.

빈 디렉터리에 Git LFS를 설치하고 새로 clone한 뒤 수정 ref를 checkout하세요. 경고와 유령 수정이 없고 복원 파일의 해시와 크기가 원본과 같은지 확인합니다.

속성, 커밋 포인터, 원격 객체와 새 작업 파일이 모두 일치할 때만 승인하고 다른 협업자나 CI clone이 통과할 때까지 백업을 보관하세요.