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

> Clean Markdown view of GeekNews topic #17461. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=17461](https://news.hada.io/topic?id=17461)
- GeekNews Markdown: [https://news.hada.io/topic/17461.md](https://news.hada.io/topic/17461.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2024-10-28T10:55:15+09:00
- Updated: 2024-10-28T10:55:15+09:00
- Original source: [jonathancreamer.com](https://www.jonathancreamer.com/how-we-shrunk-our-git-repo-size-by-94-percent/)
- Points: 7
- Comments: 1

## Summary

Microsoft의 대규모 자바스크립트 모노레포에서 발생한 git 크기 문제를 해결한 경험을 공유하며, 특히 오래된 git 패킹 코드 문제를 해결하여 레포 크기를 178GB에서 5GB로 줄인 방법을 설명합니다. CHANGELOG.md와 같은 파일의 반복적인 업데이트로 인한 문제를 해결하는 방법도 제시합니다.

## Topic Body

- 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이 있음. 이러한 도구들은 대규모 코드베이스를 효율적으로 관리하는 데 도움을 줄 수 있음.

## Comments



### Comment 30453

- Author: neo
- Created: 2024-10-28T10:55:15+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=41959428) 
- 새로운 `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자와 전체 경로 확인 문제를 더 잘 이해하고 싶음. 델타 압축, 패키지 인덱스, 멀티 패키지 인덱스와 어떻게 연결되는지 궁금함