Sparse, partial, shallow, LFS는 서로 다른 크기를 줄여
Linux kernel repo는 5GB, Chromium은 30GB가 넘고 game asset repo는 수백 GB가 될 수 있어. 일반 노트북에서 plain git clone은 고통스럽거나 불가능하지. Git에는 크기를 다루는 mechanism이 넷 있고 각자 줄이는 대상이 달라. 무엇을 포기하고 무엇을 남기는지 알고 골라야 해.
Shallow clone(git clone --depth N)은 최근 N commit만 받아 가장 빠르고 작아. 일회성 CI 실행이나 demo에는 유용하지만 git blame, git bisect와 많은 이력 query가 부정확하거나 불가능해져. 이력이 정말 필요 없을 때만 쓰고 나중에 필요해지면 git fetch --unshallow로 전체 이력을 받아.
Partial clone(git clone --filter=blob:none)은 commit과 tree object를 먼저 받고 blob은 checkout할 때까지 미뤄. Git 2.20+에서 쓸 수 있고, blob 내용이 필요 없는 이력 query는 유지하면서 파일을 실제로 볼 때만 on-demand fetch하므로 많은 작업에서 shallow보다 낫다. --filter=tree:0는 tree도 늦게 받아 매우 좁은 checkout에 유용해.
Sparse checkout은 repo tree에서 어느 path를 작업 directory에 펼칠지 골라. partial clone과 함께 쓰면 거대한 repo에서도 작은 작업 트리를 유지할 수 있어. git sparse-checkout init --cone 뒤 git sparse-checkout set frontend/ docs/를 실행하면 그 path만 채워. monorepo에서 각 engineer에게 자기 영역에 집중한 workspace를 줄 때 써.
Git LFS는 video, dataset, design asset 같은 큰 binary를 Git repo 안의 작은 pointer file로 바꾸고 본체는 별도 LFS server에 둬. Git diff와 pack은 text에 맞춰져 있어 binary가 많은 프로젝트에는 필수야. git lfs track "*.psd"로 file type을 지정하고 git-lfs hook을 설치하면 push와 pull이 binary를 LFS storage로 자동 전달해.