설명: “Not enough disk space to clone the repository”의 뜻부터 저장소가 커지는 이유, 전체 복제 없이 필요한 파일만 다루는 방법까지 정리했다.
파일 한 개만 고치려는데 작업 도구가 말한다. “저장소를 복제할 디스크 공간이 부족합니다.”
처음엔 코드가 터졌나 싶다. 하지만 이건 프로그램 실행 오류가 아니라 복사본을 받을 작업 공간의 용량 문제다. GitHub에 있던 파일이 사라졌다는 뜻도 아니다.
한 사례에서는 GitHub API가 보고한 저장소 크기가 약 9GB였다. 문서 하나 받아 오려는데 이삿짐센터가 출동한 셈이다. 볼펜 하나 빌리려다 문구점 건물째 배송받는 기분.
메시지가 알려 주는 사실
복제 작업에 필요한 여유 공간이 부족했다는 점은 확실하다. 하지만 실제로 몇 GB가 남았는지, 얼마나 내려받았는지, 현재 파일과 예전 기록 중 무엇이 공간을 차지하는지는 이 문구만으로 알 수 없다.
여기서 말하는 약 9GB는 GitHub API에 표시된 저장소 크기를 반올림한 값이다. 실패한 컴퓨터에서 복제본이 정확히 9GB였다는 측정 결과는 아니다. 내려받는 데이터, 펼쳐진 파일, 임시 작업 공간에 따라 차이가 난다.
왜 이렇게 커질까?
Git은 지금의 파일뿐 아니라 수정 기록도 관리한다. 예전에 올린 큰 사진, 백업, 자동 생성 파일이 기록에 남아 있을 수 있다. 기사와 번역본, 이미지, 결과물을 계속 추가했다면 현재 파일 자체가 커졌을 가능성도 있다.
따라서 조사할 대상은 두 가지다. 현재 파일의 크기와 과거 기록에 남은 데이터. 둘 중 무엇이 주범인지는 확인해야 한다.
GitHub는 저장소의 디스크상 크기를 10GB 이내로 유지하라는 권고를 안내한다. 이것은 10GB에서 무조건 복제가 차단된다는 뜻이 아니며, API의 크기 수치와 로컬 .git 폴더의 측정값도 같다고 단정할 수 없다.
모든 짐을 가져오지 않는 방법
예전 작업 파일이 쌓인 환경이라면 새 작업 공간에서 다시 시도할 수 있다. 다만 저장소 자체가 크다면 같은 문제가 반복될 수 있다.
파일 한 개를 읽거나 고치는 일이라면 GitHub의 파일 API로 그 파일만 처리하는 편이 낫다. Git이 꼭 필요하다면 다음처럼 기록과 내려받는 파일을 줄이는 방법이 있다.
git clone --depth=1 --filter=blob:none --sparse REPOSITORY_URL
과거 기록을 적게 받고, 파일 내용은 필요할 때 가져오며, 처음 펼치는 경로도 줄인다. 모든 환경에서 성공을 보장하는 명령은 아니고, 전체 기록이 필요한 작업에는 제약이 있다.
가장 위험한 지름길
용량이 크다고 기록을 무작정 삭제하거나 다시 쓰지 말자. 다른 사람의 작업, 기존 링크, 자동화가 영향을 받을 수 있다. 먼저 남은 디스크 공간, 현재 큰 파일, 과거 기록의 큰 데이터를 확인하고 백업한 뒤 결정해야 한다.
결론: 고장 난 건 코드보다 운반 방식
원한 건 문서 수정인데 시작하려던 작업은 9GB급 이사였다.
디스크를 늘리는 것도 방법이지만, 먼저 물어볼 게 있다. “파일 한 개 수정하는데 왜 창고를 통째로 옮기고 있지?” 운송 방식을 바꾸면 불필요한 이사부터 줄일 수 있다.
출처: GitHub 저장소 권고, 대용량 파일 안내, Git clone 문서.
