Git count-objects: Đọc dung lượng repository trước khi dọn dẹp

Repository chiếm nhiều dung lượng không có nghĩa toàn bộ phần dư đều có thể xóa. Mã nguồn đang checkout, dependency, cache build và lịch sử Git là những thành phần khác nhau. Git count-objects giúp quan sát phần lưu trữ object trước khi quyết định có cần bảo trì hay không.

1. Bắt đầu bằng phép đo chỉ đọc

git count-objects -vH
git count-objects -v

Theo tài liệu count-objects, -v cung cấp báo cáo chi tiết; -H đổi các giá trị dung lượng sang dạng dễ đọc. Dùng bản không có H khi cần ghi nhận số liệu cùng đơn vị KiB để so sánh qua thời gian.

Các bộ đếm object không phải số file nguồn hay số commit. Một ảnh được thay đổi nhiều lần có thể để lại dữ liệu lịch sử khác với kích thước ảnh đang thấy trong working tree.

2. Đừng gọi size-pack là dung lượng dự án

Hãy tách câu hỏi “Git lưu bao nhiêu object?” khỏi “thư mục dự án chiếm bao nhiêu ổ đĩa?”. Báo cáo trên không phải tổng của dependency, file build, working tree, log và mọi metadata khác. Với Git LFS hoặc submodule, cần kiểm tra phần lưu trữ tương ứng riêng.

Ví dụ, nếu thư mục dự án lớn nhưng phần object nhỏ, bước tiếp theo là đo cache và đầu ra build bằng công cụ hệ điều hành. Chạy garbage collection của Git sẽ không xử lý được một thư mục dependency lớn nằm ngoài object database.

3. Xác định đúng kho đang đo

git rev-parse --git-dir
git rev-parse --git-common-dir
git rev-parse --is-shallow-repository

Git rev-parse giúp xác định thư mục quản trị, phần dùng chung và trạng thái shallow. Với linked worktree, không nên giả định .git luôn là thư mục chứa mọi object. Ghi lại bối cảnh này trong báo cáo để tránh cộng trùng dung lượng dùng chung.

Nếu có alternate, đừng suy ra checkout đang tự chứa toàn bộ dữ liệu chỉ từ số liệu local. Trước khi sao chép hoặc loại bỏ kho nguồn, cần kiểm tra tính độc lập của bản sao bằng quy trình backup và phục hồi riêng.

4. Diễn giải theo tình huống

Nhiều object rời: ghi nhận thời điểm và thao tác vừa diễn ra. Đây là tín hiệu khảo sát cơ chế đóng gói, không tự chứng minh repository hỏng.

size-pack lớn: kiểm tra repository có lịch sử binary hoặc dữ liệu sinh tự động đã commit hay không. Chỉ xóa file khỏi phiên bản hiện tại không đồng nghĩa xóa dữ liệu lịch sử. Viết lại lịch sử là một thay đổi lớn cần thống nhất với người dùng repository, không phải bước dọn dẹp mặc định.

garbage khác 0: lưu thông báo và điều tra trạng thái kho. Không tự chọn các file trong object database để xóa thủ công. Nếu đang có sự cố lưu trữ, bảo toàn bản sao và bằng chứng trước khi thử sửa chữa.

5. Bảo trì là bước khác với đo lường

Tài liệu git gc mô tả việc đóng gói và dọn dữ liệu, đồng thời cảnh báo nguy cơ khi loại object quá sớm trong lúc tiến trình khác đang ghi. Vì vậy bài này không dùng lệnh prune tức thời làm giải pháp chung.

Trước một đợt bảo trì, nhóm nên xác nhận bản sao phục hồi được, đủ dung lượng tạm và không có tiến trình ghi xung đột. Với máy chủ dùng chung, cần người vận hành phụ trách và cửa sổ bảo trì phù hợp. Sau đó đo lại cùng điều kiện, kiểm tra hoạt động thực tế và ghi nhận thay đổi, thay vì chỉ nhìn một con số nhỏ hơn.

6. Mẫu hồ sơ chẩn đoán ngắn

• Repository và checkout đang khảo sát; không đưa credential vào hồ sơ.
• Phiên bản Git, thời điểm đo, trạng thái shallow và worktree.
• Kết quả count-objects trước và sau thao tác liên quan.
• Dung lượng working tree, dependency và cache được đo riêng.
• Triệu chứng cụ thể: thiếu ổ đĩa, fetch chậm hay thao tác local chậm.
• Bước tiếp theo và người chịu trách nhiệm, chưa tự động xóa dữ liệu.

Không có một ngưỡng object duy nhất phù hợp mọi dự án. Giá trị của count-objects nằm ở việc cung cấp bằng chứng để khoanh vùng: đo đúng thành phần, so sánh đúng bối cảnh và chỉ bảo trì khi hiểu dữ liệu nào bị tác động.