Git LFS vs. 표준 Git: 대용량 자산 성능 비교
Git LFS와 표준 Git을 대용량 자산 측면에서 비교합니다. 클론 동작, 포인터 파일, LFS 추적, 그리고 LFS를 사용할 가치가 있는 경우를 다룹니다.
Git LFS vs. 표준 Git: 대용량 자산 성능 비교
Git LFS와 표준 Git의 비교는 저장소에 대용량 바이너리 자산이 포함되기 시작할 때 실제 문제가 됩니다. 소스 코드는 일반적으로 압축 및 diff가 잘 되지만, 비디오, 디자인 파일, 게임 텍스처, 모델 파일 및 대규모 데이터셋은 클론을 느리게 만들고 히스토리 정리를 어렵게 만듭니다.
Git Large File Storage(일반적으로 Git LFS라고 함)는 선택한 파일을 작은 포인터 파일로 대체하고 실제 콘텐츠를 LFS 객체 저장소에 저장하여 일반 Git 저장소를 더 가볍게 유지합니다. 이러한 트레이드오프는 많은 팀에 도움이 되지만, 마법은 아닙니다. 여전히 올바른 파일을 선택하고, 추적 규칙을 커밋하며, LFS가 콘텐츠를 다운로드하는 시점을 이해해야 합니다.
표준 Git의 성능 병목 현상
표준 Git은 커밋된 콘텐츠를 객체 데이터베이스에 저장하고, 커밋된 모든 버전을 재구성할 수 있을 만큼 충분한 히스토리를 유지합니다. 이는 텍스트 파일에 매우 잘 작동합니다. 동일한 200MB 바이너리 파일이 여러 번 변경될 때는 제대로 작동하지 않습니다.
두 가지 문제가 빠르게 나타납니다:
- JPEG, MP4, ZIP, PSD 및 컴파일된 아티팩트와 같은 바이너리 형식은 델타 압축이 잘 되지 않는 경우가 많습니다.
- 삭제된 파일은 히스토리를 다시 쓰지 않는 한 히스토리에 남아 있습니다.
- 새 클론은 Git 히스토리에 여전히 해당 이전 객체가 포함되어 있기 때문에 이전 실수에 대한 비용을 지불합니다.
- 저장소 유지 관리 명령은 검사 및 패킹할 데이터가 더 많습니다.
예를 들어, 팀이 매 스프린트마다 대용량 내보내기 디자인 파일을 커밋하는 경우, 나중에 현재 브랜치에서 파일을 제거해도 이전 버전이 히스토리에서 제거되지는 않습니다. 새로운 개발자와 CI 작업자는 아무도 적극적으로 사용하지 않는 데이터를 계속 다운로드할 수 있습니다.
Git Large File Storage(LFS) 소개
Git LFS는 선택한 파일을 일반 Git 객체 데이터베이스 외부에서 관리하는 확장 기능입니다. 저장소는 작은 텍스트 포인터를 유지합니다. 실제 파일 콘텐츠는 Git 호스트 또는 다른 LFS 서버에서 제공하는 LFS 저장소에 저장됩니다.
포인터 시스템
LFS 포인터는 다음과 같습니다:
version https://git-lfs.github.com/spec/v1
oid sha256:4c2d44962ff3c43734e56598c199589d8995a643...a89c89
size 104857600
이 포인터가 일반 Git이 보는 것입니다. Git LFS 클라이언트는 체크아웃 또는 명시적 LFS 명령이 필요할 때 실제 파일 콘텐츠를 다운로드합니다.
성능 비교: LFS vs. 표준 Git
| 작업 | 표준 Git | Git LFS |
|---|---|---|
| 초기 클론 | 커밋된 대용량 객체를 포함하는 Git 히스토리 다운로드 | 포인터 파일이 있는 Git 히스토리 다운로드; LFS 콘텐츠는 구성에 따라 체크아웃 중에 다운로드될 수 있음 |
| 저장소 증가 | 대용량 바이너리가 .git 히스토리를 부풀릴 수 있음 |
추적된 파일 콘텐츠가 외부에 있으므로 Git 히스토리가 더 작게 유지됨 |
| 체크아웃 | 이미 Git 데이터베이스에 있는 객체 사용 | 체크아웃된 커밋에 대해 LFS 객체를 가져와야 할 수 있음 |
| CI 작업 | 히스토리 자산 다운로드에 시간 낭비 가능 | 빌드에 자산이 필요하지 않은 경우 LFS 다운로드를 건너뛰거나 제한할 수 있음 |
| 정리 | 이전에 커밋된 blob을 제거하기 위해 히스토리 재작성 필요 | 여전히 주의가 필요하지만, 새 LFS 추적 버전은 일반 Git 히스토리를 부풀리지 않음 |
중요한 세부 사항은 체크아웃 동작입니다. Git LFS가 설치된 일반 git clone은 체크아웃된 커밋에 필요한 LFS 파일을 종종 다운로드합니다. 포인터만 원하는 경우 클론 중에 GIT_LFS_SKIP_SMUDGE=1을 사용하고 나중에 git lfs pull로 파일을 가져옵니다.
Git LFS를 사용해야 하는 경우
Git LFS는 크고 바이너리이며 변경이 예상되는 파일에 적합합니다. 일반적인 예는 다음과 같습니다:
*.psd,*.tiff,*.blend및 기타 디자인 또는 3D 자산.*.mp4,*.mov,*.wav및 기타 미디어 파일.- 프로젝트에 필요한 대용량 모델 파일, 테스트 픽스처 또는 데이터셋.
- 프로젝트에 버전을 관리해야 하는 명확한 이유가 있는 경우에만 컴파일된 바이너리.
가능하다고 해서 모든 파일을 LFS에 넣지 마십시오. 텍스트 파일, 소스 코드, 작은 구성 파일 및 Git이 정상적으로 diff하기를 원하는 파일은 표준 Git에 남아 있어야 합니다.
LFS를 채택하기 전에 호스팅 제공업체의 저장소 및 대역폭 제한을 확인하십시오. GitHub, GitLab, Bitbucket 및 자체 호스팅 플랫폼은 할당량, 청구 및 보존 동작이 다를 수 있습니다.
Git LFS 구현
Git LFS 클라이언트를 설치한 다음 사용자에 대한 후크를 활성화합니다:
git lfs install
LFS가 관리할 패턴을 추적합니다:
git lfs track "*.psd"
git lfs track "assets/*.mp4"
이 명령은 .gitattributes를 생성하거나 업데이트합니다. 해당 파일을 영향을 받는 자산과 함께 커밋합니다:
git add .gitattributes assets/
git commit -m "Track design assets with Git LFS"
git push
대용량 파일이 이미 일반 Git 히스토리에 커밋된 경우 LFS로 추적하면 향후 커밋에만 영향을 미칩니다. 기존 히스토리를 마이그레이션하려면 git lfs migrate import와 같은 마이그레이션 도구를 사용하고, 히스토리 재작성으로 인해 커밋 ID가 변경되므로 신중하게 조정하십시오.
LFS 콘텐츠를 즉시 다운로드하지 않고 클론하려면 다음을 사용합니다:
GIT_LFS_SKIP_SMUDGE=1 git clone [email protected]:example/assets-heavy-repo.git
cd assets-heavy-repo
git lfs pull --include="assets/*.mp4"
실용적인 결론
소스 코드와 작은 텍스트 파일에는 표준 Git을 사용하십시오. 저장소에 속하지만 일반 Git 히스토리를 부풀리지 않아야 하는 대용량 바이너리 자산에는 Git LFS를 사용하십시오.
팀 저장소의 경우, 초기에 LFS 규칙을 추가하고, .gitattributes를 커밋하고, CI가 LFS 다운로드를 처리하는 방법을 문서화하고, 호스트의 LFS 제한을 확인하십시오. 이렇게 하면 클론, 체크아웃 또는 릴리스 빌드 중에 개발자를 놀라게 하지 않으면서 성능 이점을 얻을 수 있습니다.