- 1JS, monorepo JavaScript quy mô lớn của Microsoft, có lượng mã nguồn và đóng góp rất lớn. Một bản clone gần đây của repo đã lên tới 178GB.
- Kích thước repo quá lớn đến mức một số người dùng ở châu Âu không thể clone được.
Bài học #1
- Khi tham gia vào repo vài năm trước, nhóm đã nhận ra repo tăng kích thước rất nhanh. Lúc clone lần đầu chỉ khoảng 1~2GB, nhưng vài tháng sau đã đạt 4GB.
- Nhóm đã dùng công cụ
git-sizer để kiểm tra các blob lớn, và phát hiện điều này xảy ra khi file nhị phân bị check in nhầm. Có thể ngăn việc này bằng tính năng giới hạn kích thước check-in của Azure DevOps.
- Việc không xóa các file thay đổi của Beachball đã gây ra vấn đề. Cơ chế này, tương tự Changesets, được dùng để tự động tăng phạm vi semver của package.
- Nhóm rút ra bài học là không nên giữ hàng nghìn file trong một thư mục. Để giải quyết, họ đã gửi một pull request cho Beachball để xử lý nhiều thay đổi trong một file, đồng thời viết một pipeline dọn dẹp thư mục thay đổi định kỳ.
Bài học #2
- Nhánh
versioned, bản mirror của main, ngày càng khó clone hơn. Dù chỉ có CHANGELOG.md và CHANGELOG.json thay đổi, nó vẫn kéo thêm 125GB dữ liệu git.
- Nhóm phát hiện mã đóng gói cũ do Linux Torvalds check in thực hiện nén bằng cách chỉ so sánh 16 ký tự cuối của tên file. Vì vậy git liên tục push toàn bộ file khi so sánh với các file
CHANGELOG.md của package khác.
- Nhóm đã dùng lệnh
git repack -adf --window=250 để giảm kích thước repo, và với lệnh mới git repack -adf --path-walk đã giảm từ 178GB xuống còn 5GB.
- Họ thêm cấu hình
git config --global pack.usePathWalk true để tạo đúng delta khi git push.
Kết thúc
- Nếu trong monorepo quy mô lớn có các file tên dài như
CHANGELOG.md được cập nhật thường xuyên, bạn nên chú ý đến tính năng path walk.
- Có thể dùng lệnh
git survey để xem các file đứng đầu theo dung lượng trên đĩa, các thư mục đứng đầu theo kích thước phình to, v.v.
- Microsoft đang phát triển các giải pháp cho việc mở rộng repository và cung cấp chúng trên toàn cầu.
Tóm tắt của GN⁺
- Bài viết này chia sẻ kinh nghiệm giảm kích thước git của một monorepo JavaScript quy mô lớn. Đặc biệt, họ đã giải quyết vấn đề trong mã đóng gói git cũ để cắt giảm mạnh kích thước repo.
- Bài viết cung cấp thông tin hữu ích để xử lý các vấn đề liên quan đến git có thể phát sinh trong các dự án lớn. Cụ thể, nó giải thích cách xử lý vấn đề do việc cập nhật lặp lại các file như
CHANGELOG.md.
- Các dự án có chức năng tương tự gồm có Buck của Facebook hoặc Bazel của Google. Những công cụ này có thể giúp quản lý hiệu quả các codebase lớn.
1 bình luận
Ý kiến Hacker News
Lệnh
git-surveymới vẫn chưa được đưa vàogit.git. Nó được thêm vào trong bản fork Git của MicrosoftKhi clone
nixpkgs, tùy chọn--window 250đã giảm kích thước xuống còn 1.7GB. Tùy chọn--path-walktrong bản fork Git của Microsoft đã giảm xuống còn 1.9GBMột số người dùng ở châu Âu nói rằng họ không thể clone các repo lớn. Có vẻ như sẽ không thể clone được cho tới khi có thay đổi ở phía máy chủ
Sự cố xảy ra do một sai lầm khiến tên tệp không bao gồm toàn bộ đường dẫn. Họ chỉ đang kiểm tra 16 ký tự cuối cùng
Derick Stolee đã viết blog về cấu trúc bên trong của Git. Có thể học được rất nhiều về cách giảm kích thước
git clonetrên máy cục bộ và trong CIViệc hack Git thì rất thú vị, nhưng tôi tự hỏi liệu có cách nào để không đưa 2.500 package vào monorepo hay không
Microsoft nên tự dùng Azure DevOps. Có vẻ như các dịch vụ Azure chỉ cung cấp connector native cho GitHub
Có một người rất hiểu cấu trúc bên trong của Git ở gần là một lợi thế lớn khi làm việc trong các dự án lớn
Cảm ơn bài viết này. Nó đã giúp ích rất nhiều cho phần mềm mã nguồn mở. Microsoft, GitHub và GitLab đang mang lại nhiều điều tốt đẹp
Tôi muốn hiểu rõ hơn về vấn đề kiểm tra 16 ký tự cuối cùng và toàn bộ đường dẫn. Tôi tò mò nó liên quan thế nào tới nén delta, chỉ mục package và chỉ mục đa package