Sparse, partial, shallow, LFS — 큰 거 다루는 네 방법
Linux 커널 repo 는 5 GB. Chromium repo 는 30+ GB. 게임 asset repo 는 수백 GB 가능. 일반 노트북에서 plain git clone 은 고통스럽거나 불가능. Git 은 크기 다루는 메커니즘 넷, 각자 다른 문제 해결. 어느 걸 잡을지 아는 게 중요.
Shallow clone (git clone --depth N) 이 가장 최근 N commit 만 다운로드. 가장 빠른 clone, 가장 작은 다운로드, 일회성 CI run + 데모에 유용. 비용: git blame, git bisect, 대부분 history query 가 부정확 / 불가능. 진짜 history 안 필요할 때만 shallow. 필요해지면 git fetch --unshallow 로 full history 승격.
Partial clone (git clone --filter=blob:none 과 친구들) 이 commit + tree object 만 다운로드, blob fetch 는 checkout 까지 미룸. Modern, Git 2.20 부터 가능. 대부분 workflow 에 shallow 보다 나음: blob 내용 안 필요한 history query 빠르게 유지, 파일 실제로 볼 때 blob 이 on-demand fetch. --filter=tree:0 가 tree 다운로드도 미룸, 매우 좁은 checkout 에 유용.
Sparse checkout 이 repo tree 의 어느 path 가 working 디렉토리에 실체화될지 선택. Partial clone 과 결합하면 거대 repo 에서도 작은 working tree. git sparse-checkout init --cone + git sparse-checkout set frontend/ docs/ 가 그 path 만 채움. Monorepo 가 엔지니어마다 집중된 workspace 주는 데 사용.
Git LFS ('Large File Storage') 가 큰 binary 파일 (영상, 데이터셋, 디자인 asset) 을 Git repo 의 작은 pointer 파일로 교체, 실제 binary 는 전용 LFS 서버에 살게. Binary 많은 프로젝트엔 필수 — Git diff / pack 이 텍스트 최적화라서. git lfs track "*.psd" 로 파일 타입 추적, git-lfs hook 한 번 설치, push/pull 이 자동으로 binary 를 LFS storage 로 라우팅.