Git sparse-checkout은 작업 트리에 나타나는 경로를 줄이고, partial clone은 처음 가져오는 객체를 줄인다. shallow clone은 커밋 이력의 범위를 줄이는 또 다른 선택이다. 큰 저장소에서 이들을 같은 기능으로 생각하면 디스크 사용량이나 오프라인 작업에 대한 기대가 어긋날 수 있다. 무엇을 줄이려는지부터 구분해야 한다.

작업 파일과 객체와 이력을 구분한 개념도

실제 저장소나 성능 측정 결과가 아닌 개념 설명이다.

작업 트리와 객체 저장소는 다른 공간이다

공식 sparse-checkout 문서는 선택한 디렉터리나 패턴에 맞는 파일을 작업 트리에 두는 기능을 설명한다. 편집기에서 일부 폴더만 보인다고 저장소의 모든 객체가 사라진 것은 아니다. 작업 트리는 현재 편집할 파일의 모습이고 객체 저장소는 Git이 이력과 내용을 다루는 기반이다.

예를 들어 큰 모노레포에서 한 서비스 폴더만 편집하려면 작업 트리의 범위를 줄이는 것이 목적에 맞는다. 그러나 저장소 전체를 이미 내려받았다면 화면에서 폴더를 숨기는 것만으로 최초 다운로드를 되돌리지는 않는다. 가져오는 데이터와 보이는 파일을 각각 측정해야 효과를 판단할 수 있다. 작업 트리 매뉴얼

cone mode는 디렉터리 선택을 중심으로 한다

공식 문서에서 cone mode는 디렉터리 목록을 중심으로 범위를 정한다. 임의 패턴을 사용하는 방식과 다르며 문서는 non-cone 방식의 단점도 설명한다. 일반적인 서비스 폴더 선택에는 먼저 디렉터리 기반 모델을 이해하는 편이 관리하기 쉽다. 모든 패턴 규칙을 동등한 비용의 선택으로 볼 수는 없다.

선택 밖의 파일이 보이지 않는 상황을 파일 삭제와 혼동하지 않아야 한다. sparse-checkout 환경에서는 다른 Git 명령도 경로 범위를 고려해 동작한다. 또한 병합이나 충돌 처리 중 필요한 경로가 실제 파일로 나타날 수 있다. 문서의 reapply 설명은 이런 경우 충돌을 해결하고 영향을 받은 변경을 정리한 뒤 작업 트리를 다시 원하는 범위로 맞추는 절차를 다룬다.

cone 선택은 고른 디렉터리 아래를 재귀적으로 포함하며 루트와 그 디렉터리까지의 조상 위치에 있는 파일도 포함한다. 가상의 services/api 선택에서는 루트의 파일과 services 바로 아래 파일이 함께 보일 수 있다. 그렇다고 services/web 같은 형제 디렉터리 전체를 재귀적으로 선택하는 것은 아니다. 폴더 목록만 비교하면 이런 포함 규칙을 놓치므로 파일 위치까지 구분해야 한다. cone 포함 규칙

전문 관점: 객체를 늦게 받는 비용

Git 개발자 Derrick Stolee의 GitHub 전문 분석은 blobless partial clone이 도달 가능한 커밋과 트리를 받고 파일 내용인 blob은 필요할 때 가져오는 방식이라고 설명한다. 파일 목록과 이력의 구조를 먼저 갖추되 모든 과거 파일 내용을 처음부터 받지는 않는 선택이다. 이 설명은 2020년 글로, 현재 환경의 지원 조건은 별도 확인해야 한다.

나중에 필요한 내용을 서버에서 받는다는 것은 이후 작업에 네트워크 접근이 필요할 수 있다는 뜻이다. 첫 다운로드가 작아졌다는 사실만으로 모든 명령이 더 빠르거나 완전한 오프라인 작업이 가능하다고 결론 내리면 안 된다. 평소 사용하는 diff나 과거 버전 조사에서 어떤 내용이 필요해지는지 살펴보는 것이 실무적인 확인 방법이다.

git clone --sparse는 처음에 최상위 파일만 작업 트리에 둔다. --filter=blob:none만으로 최초 체크아웃의 blob 다운로드까지 없어지는 것은 아니다. 체크아웃을 생략하는 --no-checkout은 별도 선택이다. 필터 요청은 서버 지원에 달려 있으며 거부될 수도 있다. 이미 받은 객체는 로컬에서 쓸 수 있고, 모든 명령이 매번 원격에 접속하는 것은 아니다. clone 옵션의 범위 누락 객체의 원격 의존성 과거 저자 분석

shallow clone은 이력 경계를 바꾼다

같은 전문 분석은 shallow clone이 커밋 이력을 잘라 가져온다고 구분한다. 파일 내용 객체를 나중에 받는 것과 이력의 일부를 갖고 있지 않은 것은 다른 제약이다. 현재 스냅샷을 빌드하는 일회성 작업과 오래된 변경을 조사하는 개발 환경은 필요한 이력의 범위가 다르다.

따라서 clone이 끝난 시간만으로 선택하지 말고 이후 수행할 일을 적어야 한다. 과거 원인 추적이나 브랜치 관계 조사에 필요한 이력이 충분한지 확인한다. 저장소와 서버의 실제 지원, 이후 fetch의 사용 방식도 함께 봐야 한다. 글의 특정 환경별 권고를 모든 CI와 개발자 환경에 그대로 적용할 수는 없다. 이력 범위 옵션

조합을 선택할 때 확인할 항목

작업 폴더 수, 최초 다운로드 크기, 이후 원격 요청, 필요한 이력이라는 네 항목으로 목적을 정리하면 기능 선택이 분명해진다. sparse-checkout과 partial clone은 다른 층을 줄이므로 함께 고려할 수 있지만 빌드 도구가 선택 밖의 파일을 필요로 하는지도 확인해야 한다. 좁은 작업 트리만 보고 빌드 입력이 모두 준비됐다고 판단해서는 안 된다.

공식 문서가 설명하는 sparse index는 인덱스 표현을 줄이는 추가 선택이며 외부 도구와의 호환성 검토가 필요하다. 이는 파일 표시나 객체 다운로드와도 구분된다. 기존 작업 변경을 보존한 별도 환경에서 사용 중인 편집기와 빌드 흐름을 확인하면, 무엇이 줄었고 어떤 원격 의존성이 남았는지 실제로 판단할 수 있다. 인덱스 호환성 설치된 Git 버전과 외부 도구는 현재 매뉴얼의 동작과 다를 수 있다.

출처