The Story of Scalar | The GitHub Blog
The GitHub Blog
이번 Git 2.38.0 버전에 scalar라는 새로운 명령어가 추가되었습니다. 이 명령어는 엄청나게 큰 모노레포를 다루기 위해서 추가된 명령어인데 이 글은 scalar를 만들어서 Git에 추가하기 까지의 과정을 담고 있습니다.
오래전에 글을 봤었는데 Microsoft에서는 Windows의 저장소가 너무 커서 협업하기 어려움이 있었고 새로 clone에 12시간이 걸리고 checkout에만 3시간이 걸려서 VFS for Git이라는 프로젝트를 2017년에 만들어서 사용하고 있었습니다. 이는 전체 저장소를 다 가져오기 어려우리 파일을 실제로 사용할 때만 가져오도록 만들었습니다.
이 노력이 scalar로 이어진 걸로 보이는데 이후 MS Office에서도 VFS for Git을 쓰려고 하다보니 오피스에서는 macOS도 지원해야 했지만 macOS에서는 VFS for Git을 쓸 수 없었다고 합니다. 그래서 sparse checkout에 cone 모드를 추가해서 VFS와 비슷한 성능을 얻을 수 있었고 이를 통해 VFS for Git과 별개로 만들기로 결정하고 scalar가 시작하게 됩니다.
Scalar 의도에 맞게 아키텍처를 개선하다보니 Git을 감싸고 있는 CLI 형태가 되었고 거대한 모노레포의 문제가 Microsoft에만 있는 것은 아니므로 Git 업스트림에 기여하기 시작해서 이번 릴리스에 포함되었다고 합니다.
git clone 대신 scalar clone 명령어를 사용하면 대규모 저장소의 성능과관련된 기능이 포함되어 있습니다.
다음 내용이 궁금하다면?
이미 회원이신가요?
2022년 10월 17일 오전 4:36
댓글 0
함께 읽은 게시물
프론트엔드 성능 최적화: 토스 개발팀의 전략과 인사이트
사
... 더 보기
2025 쿠팡이츠 테크 신입 개발자 공개 채용
안
... 더 보기🧊 급격하게 얼어붙고 있는 해외 취업 시장 🥶
최근 한국에 아는 개발자 분께서 미국에서 근무할 수 있는 포지션의 최종 면접을 앞두고 있었는데 갑자기 채용이 무기한 연기되었다는 황당한 소식을 듣게 되셨습니다. 다른 개발자 분께서는 심지어 최종 합격을 하고 리로케이션 패키지까지 받았는데, 느닷없이 오퍼가 취
... 더 보기< '다들 하니까'의 함정: 우리는 왜 내 판단보다 다수의 판단을 믿을까
1. 사람들은 현재를, 지금까지 벌어진 일을 보여주는 지난 경험에 대한 솔직한 평가가 아니라 미래를 예측하는 유용한 지침이라고 생각하는 경향이 있다.
IT 회사의 업무에서, 지금까지는 디자이너와 특히 개발자가 병목이었는데, 대 AI 시대에는 기획자가 병목이 될 수도 있겠다. 조금이라도 규모가 있는 기업에서의 가장 큰 병목은 보통 의사결정자라는 것을 생각해보면 그렇다.
즉, 실무보다 의사결정을 AI에게 맡기는 것이 병목을 해소할 수 있는 가장 확실한 방법이며, 그러므로 부장님과 사장님을 AI로 대체하는 것이야말로 인류의 번영을 위한 가장 빠른 지름길이다. (아님. 아니 맞나?!)
