Repo GitHub của bạn nặng bao nhiêu?

Repo GitHub của bạn nặng bao nhiêu?

GitHub không hiện dung lượng repo trên giao diện — nhưng có cách kiểm tra trong 10 giây. Và con số đó có thể khiến bạn giật mình.

Kịch bản lúc 9 giờ sáng thứ Hai

Giả sử bạn vừa onboard một dev mới vào team. Bạn hào hứng gửi link repo, bảo "clone về rồi chạy thôi." Mười lăm phút sau, dev mới vẫn ngồi nhìn terminal — progress bar mới 30%.

Bạn ngạc nhiên: "Ủa, hồi mình clone có lâu vậy đâu?" Đúng rồi — hồi đó repo mới 200MB, giờ nó 2GB mà không ai hay.

Phần oái oăm nhất? GitHub không hiện dung lượng repo ở bất kỳ đâu trên giao diện. Bạn thấy số sao, số fork, ngôn ngữ chính — nhưng cái thông tin cơ bản nhất thì lại phải tự đi tìm.

Kiểm tra trong đúng 10 giây

Simon Willison vừa chia sẻ một tool nhỏ mà gọn: paste URL repo vào, biết ngay dung lượng.

Cách hoạt động đơn giản đến bất ngờ: GitHub API trả về thông tin size cho mọi public repo — và API này hỗ trợ CORS, nghĩa là trình duyệt gọi được trực tiếp, không cần backend gì cả.

Thử ngay:

  1. Mở tool GitHub Repo Size
  2. Paste URL repo bạn muốn kiểm tra
  3. Xong — con số hiện ra ngay

Ví dụ minh họa: repo simonw/datasette — một project Python khá nổi tiếng — chỉ nặng 8.1MB. Nếu repo của team bạn nặng hơn vài trăm MB mà code không nhiều tương ứng, có lẽ đã đến lúc hỏi "tại sao?"

Hoặc nếu thích dùng terminal, một dòng curl là đủ:

curl -s https://api.github.com/repos/OWNER/REPO | grep '"size"'

Kết quả trả về đơn vị KB — chia cho 1024 là ra MB.

Repo phình to — chuyện nhỏ mà không nhỏ

Dung lượng repo nghe có vẻ là thông tin "biết cũng được, không biết cũng chẳng sao." Nhưng nó ảnh hưởng thật sự đến workflow hằng ngày. Dịch sang tiếng người:

Hình dung thế này: repo giống một công trình xây dựng. Ban đầu bản vẽ sạch sẽ, vật liệu ngăn nắp. Nhưng dần dần — mỗi sprint thêm vài bao cát để đó, mấy tấm ván khuôn cũ chẳng ai dọn, vài cuộn thép thừa "để phòng khi cần." Mỗi thứ đều nhỏ, nhưng gộp lại thì công trình ngập phế liệu mà không ai nhận ra — cho đến khi xe cẩu không vào được.

Bẫy kinh điển: "Xóa rồi mà!"

Đây là cái bẫy team nào cũng dính ít nhất một lần.

Ai đó commit nhầm file model.bin 500MB. Nhận ra sai, xóa đi, commit lại. Thở phào.

Nhưng khoan — Git nhớ tất cả. File đó vẫn nằm nguyên trong lịch sử, và mỗi lần ai clone, vẫn tải trọn 500MB đó về.

Nói thẳng ra: git rm chỉ xóa file khỏi thư mục làm việc, không xóa khỏi lịch sử. Muốn dọn thật sự, bạn cần công cụ chuyên dụng.

Một kịch bản quen thuộc: Giả sử team 5 người làm product AI. Bạn data engineer commit nhầm tập dataset 1.2GB vào repo chính. Xóa commit sau, nhưng repo vẫn nặng nguyên. CI/CD bỗng chạy chậm hẳn, cả tuần debug mà không ai nghĩ đến nguyên nhân "tầm thường" này — cho đến khi kiểm tra dung lượng repo.

5 bước dọn dẹp trong một buổi chiều

Bạn có 2 tiếng? Thừa sức.

Bước 1 — Kiểm tra dung lượng hiện tại bằng tool ở trên. Ghi lại con số làm baseline.

Bước 2 — Tìm "phế liệu" trong lịch sử git:

git rev-list --objects --all | \
  git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | \
  grep '^blob' | sort -rnk3 | head -20

Lệnh này liệt kê 20 object lớn nhất từng tồn tại — kể cả file đã "xóa."

Bước 3 — Rà lại .gitignore. Đảm bảo những thứ này không bao giờ lọt vào repo:

Bước 4 — Nếu phát hiện file lớn trong lịch sử, dùng git-filter-repo (open-source) để dọn:

pip install git-filter-repo
git filter-repo --strip-blobs-bigger-than 10M

⚠️ Lệnh này rewrite lịch sử — backup trước, và thông báo cả team force-pull sau khi xong.

Một lựa chọn khác là BFG Repo-Cleaner — cũng open-source, syntax đơn giản hơn cho việc xóa file cụ thể.

Bước 5 — File lớn cần thiết (model, dataset) thì chuyển sang Git LFS:

git lfs install
git lfs track "*.bin"
git add .gitattributes

LFS lưu file lớn riêng, repo chính chỉ giữ pointer — nhẹ hơn hẳn.

Biến thành thói quen, đừng để thành nợ kỹ thuật

Dọn một lần thì ai cũng làm được. Giữ cho sạch lâu dài mới là bài toán thật.

Pre-commit hook kiểm tra file size — reject ngay nếu ai commit file vượt ngưỡng. Tool pre-commit (open-source) có sẵn rule check-added-large-files, cài trong 2 phút.

CI check in ra dung lượng repo mỗi lần merge vào main — giống đo huyết áp, đo thường xuyên thì phát hiện bất thường sớm.

Quy ước team đơn giản: mọi binary file phải qua LFS, không có ngoại lệ. Viết vào wiki, nhắc trong onboarding.

Repo gọn thì clone nhanh, CI nhanh, dev mới vào làm việc được ngay thay vì ngồi chờ progress bar. Đôi khi cải thiện developer experience không cần framework mới hay tool xịn — chỉ cần biết căn nhà mình đang chứa bao nhiêu đồ thừa.

Đừng tin mình, thử đi rồi biết.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo