Git으로 대규모 리포지토리를 다루는 방법

리포지토리가 커지는 이유는 크게 두 가지가 있습니다.

• 매우 긴 기록 축적(프로젝트는 매우 긴 기간에 걸쳐 늘어나고 기록이 축적됨)
• 코드와 함께 추적되고 사용되어야 하는 대규모 바이너리 자산이 포함됩니다.

...또는 둘 다일 수도 있습니다.

때때로 두 번째 유형의 문제는 더 이상 사용되지 않는 오래된 바이너리 아티팩트가 여전히 리포지토리에 저장되어 있다는 사실 때문에 복잡해집니다. 하지만 성가시더라도 비교적 쉽게 해결할 수 있는 방법이 있습니다(아래 참조).

각 시나리오에 대한 기법과 해결 방법은 서로 다르며 때로는 상호 보완적이기도 합니다. 따라서 별도로 다루도록 하겠습니다.

대규모 리포지토리의 두 번째 유형은 대규모 바이너리 자산이 있는 리포지토리입니다. 이러한 리포지토리는 여러 유형의 소프트웨어 팀과 소프트웨어 분야 이외의 팀이 마주하게 됩니다. 게임 팀은 대규모 3D 모델을 다루어야 하고, 웹 개발 팀은 원시 이미지 자산을 추적해야 하며, CAD 팀은 바이너리 결과물의 상태를 조작하고 추적해야 할 수도 있습니다.

Git은 바이너리 자산을 다루는 데 딱히 나쁘지는 않지만 특별히 좋지도 않습니다. Git은 기본적으로 바이너리 자산의 모든 후속 전체 버전을 압축하고 저장하므로 바이너리 자산이 많을 경우 최적이라고 할 수 없습니다.

가비지 컬렉션(‘git gc’)을 실행하거나 .gitattributes에서 일부 바이너리 유형에 대한 델타 커밋의 사용 조정과 같이 상황을 개선하는 몇 가지 기본적인 조정이 있습니다.

하지만 성공적인 접근 방식을 결정하는 데 도움이 될 수 있으므로 프로젝트의 바이너리 자산 특성을 되돌아보는 것이 중요합니다. 예를 들어, 고려해야 할 몇 가지 사항은 다음과 같습니다.

• 일부 메타 데이터 헤더뿐만 아니라 크게 변경되는 바이너리 파일의 경우 델타 압축은 아마 쓸모가 없을 것이므로 델타 압축이 리패키징의 일부로 불필요하게 작동하지 않도록 해당 파일에 ‘델타 비활성화’ 를 사용하세요.
• 위 시나리오에서는 파일이 제대로 zlib 압축되지 않을 가능성이 높으므로 ‘core.compression 0’ 또는 ‘core.loosecompression 0’으로 압축을 비활성화할 수 있습니다. 실제로 압축이 잘 되는 바이너리 파일이 아닌 모든 파일에 부정적인 영향을 미치는 전역 설정이므로 바이너리 자산을 별도의 리포지토리로 분할하는 것이 좋습니다.
• ‘git gc’는 "복제된" 느슨한 개체를 단일 팩 파일로 변환하지만 파일이 압축되지 않는 한 결과로 만들어지는 팩 파일과 비교하여 큰 차이가 없다는 사실을 기억해야 합니다.
• ‘core.bigFileThreshold’ 튜닝을 탐색합니다. 512MB보다 큰 것은 .gitattributes 설정 없이는 델타 압축되지 않기 때문에 조정하는 것이 좋습니다.

대용량 파일로 정기적으로 작업하는 경우 가장 좋은 방법은 2015년 Atlassian이 GitHub와 공동 개발한 LFS(Large File Storage)를 활용하는 것입니다. (맞습니다. Atlassian은 Git 프로젝트에 오픈 소스 기여를 하기 위해 GitHub와 협력했습니다.)

Git LFS는 리포지토리의 대용량 파일에 파일 자체를 저장하는 대신 포인터를 저장하는 확장 기능입니다. 실제 파일은 원격 서버에 저장됩니다. 이렇게 하면 리포지토리를 복제하는 데 걸리는 시간이 대폭 줄어듭니다.

리포지토리 기록이 크거나 파일이 크다는 이유만으로 Git의 환상적인 기능을 포기하지 마세요. 두 가지 문제에 대한 실행 가능한 솔루션이 있습니다.

하위 모듈, 프로젝트 종속성, Git LFS에 대한 자세한 내용은 위에 링크한 다른 글에서 확인해 보세요. 명령과 워크플로에 대한 복습을 위해 Git 마이크로사이트에 수많은 자습서가 준비되어 있습니다. 즐겁게 코딩하세요!