▲

GN⁺: 우리는 어떻게 자바스크립트 모노레포 git 크기를 94% 줄였는가

 (jonathancreamer.com)
7P by neo 29일전 | favorite | 댓글 1개
  • Microsoft의 대규모 자바스크립트 모노레포인 1JS는 코드와 기여의 양이 매우 많음. 최근 클론한 레포는 178GB에 달했음.
  • 레포의 크기가 너무 커서 유럽의 일부 사용자들은 클론할 수 없었음.

교훈 #1

  • 몇 년 전 레포에 합류했을 때, 레포가 빠르게 커지는 것을 발견했음. 처음 클론했을 때는 1~2GB였지만 몇 달 후에는 이미 4GB에 달했음.
  • git-sizer 도구를 사용하여 큰 blob을 확인했으며, 이는 바이너리가 실수로 체크인될 때 발생함. Azure DevOps의 체크인 크기 제한 기능을 사용하여 이를 방지할 수 있음.
  • Beachball 변경 파일을 삭제하지 않아 문제가 발생했음. 이는 Changesets와 유사하게 패키지의 semver 범위를 자동으로 증가시키는 데 사용됨.
  • 하나의 폴더에 수천 개의 파일을 보관하지 말라는 교훈을 얻었음. 이를 해결하기 위해 Beachball에 여러 변경을 하나의 파일로 처리하는 풀 리퀘스트를 제출하고, 변경 폴더를 주기적으로 정리하는 파이프라인을 작성했음.

교훈 #2

  • main의 미러인 versioned 브랜치가 점점 더 클론하기 어려워졌음. CHANGELOG.md와 CHANGELOG.json 파일만 변경되었는데도 불구하고, 125GB의 추가 git 데이터를 가져오고 있었음.
  • Linux Torvalds가 체크인한 오래된 패킹 코드가 파일 이름의 마지막 16자만 비교하여 압축을 수행하는 문제를 발견했음. 이로 인해 git이 다른 패키지의 CHANGELOG.md 파일과 비교하여 전체 파일을 반복적으로 푸시하게 되었음.
  • git repack -adf --window=250 명령어를 사용하여 레포의 크기를 줄였으며, 새로운 git repack -adf --path-walk 명령어를 사용하여 178GB에서 5GB로 줄였음.
  • git config --global pack.usePathWalk true 설정을 추가하여 git push 시 올바른 델타가 생성되도록 함.

마무리

  • 대규모 모노레포에서 CHANGELOG.md와 같은 긴 이름의 파일이 자주 업데이트되는 경우, path walk 기능을 주목해야 함.
  • git survey 명령어를 사용하여 디스크 크기별 상위 파일, 팽창된 크기별 상위 디렉토리 등을 확인할 수 있음.
  • Microsoft에서 레포지토리 확장을 위한 솔루션을 개발하고 있으며, 이를 전 세계에 제공하고 있음.

GN⁺의 정리

  • 이 글은 대규모 자바스크립트 모노레포의 git 크기를 줄이는 방법에 대한 경험을 공유함. 특히, 오래된 git 패킹 코드의 문제를 해결하여 레포 크기를 크게 줄였음.
  • 이 글은 대규모 프로젝트에서 발생할 수 있는 git 관련 문제를 해결하는 데 유용한 정보를 제공함. 특히, CHANGELOG.md와 같은 파일의 반복적인 업데이트로 인한 문제를 해결하는 방법을 설명함.
  • 유사한 기능을 가진 프로젝트로는 Facebook의 Buck이나 Google의 Bazel이 있음. 이러한 도구들은 대규모 코드베이스를 효율적으로 관리하는 데 도움을 줄 수 있음.
▲
neo 29일전  [-]
Hacker News 의견

  • 새로운 git-survey 명령어는 아직 git.git에 포함되지 않았음. Microsoft의 git fork에서 추가된 것임

  • nixpkgs를 클론했을 때, --window 250 옵션은 크기를 1.7GB로 줄였음. Microsoft git fork의 --path-walk 옵션은 1.9GB로 줄였음

    • 두 옵션 모두 초기 크기의 절반 이하로 줄였음
    • GitHub에서 이를 실행할 수 있으면 좋겠고, 사람들이 이를 제어할 수 있는 방식으로 호스팅하면 더 좋을 것임

  • 유럽의 일부 사용자는 큰 레포지토리를 클론할 수 없다고 함. 서버 측에서 변경이 이루어지기 전까지는 클론이 불가능할 것 같음

  • 파일 이름에 전체 경로가 포함되지 않는 실수로 인해 문제가 발생했음. 마지막 16자만 확인하고 있었음

  • Derick Stolee가 git 내부 구조에 대한 블로그를 작성했음. 로컬 및 CI에서 git clone 크기를 줄이는 방법에 대해 많은 것을 배울 수 있었음

  • Git을 해킹하는 것은 재미있지만, 2,500개의 패키지를 모노레포에 포함하지 않는 방법이 있는지 궁금함

  • Microsoft가 Azure DevOps를 자체적으로 사용하는 것이 좋음. Azure 서비스가 GitHub에만 네이티브 커넥터를 제공하는 것 같음

  • Git의 내부 구조를 잘 아는 사람이 가까이에 있는 것은 큰 프로젝트에서 일할 때 좋은 혜택임

  • 이 게시물에 감사함. 오픈 소스 소프트웨어에 큰 도움이 되었음. Microsoft, GitHub, GitLab이 많은 좋은 것을 제공하고 있음

  • 마지막 16자와 전체 경로 확인 문제를 더 잘 이해하고 싶음. 델타 압축, 패키지 인덱스, 멀티 패키지 인덱스와 어떻게 연결되는지 궁금함

답변달기