Một commit Git thực sự chiếm bao nhiêu dung lượng?

Khi làm việc với Git mỗi ngày, ít ai trong chúng ta để ý rằng mỗi lần commit, Git lại âm thầm ghi thêm một lượng dữ liệu vào thư mục .git. Câu hỏi tưởng chừng đơn giản — "một commit Git lớn cỡ nào?" — lại có câu trả lời khá thú vị: còn tùy. Bài viết này sẽ mổ xẻ chi tiết cách Git lưu trữ dữ liệu và con số thực tế qua các thử nghiệm cụ thể.

Câu trả lời ngắn: Còn tùy vào dữ liệu của bạn

Git lưu trữ mọi thứ dưới dạng các "object" được nén bằng zlib. Điều này có nghĩa là kích thước chính xác của một commit phụ thuộc vào mức độ nén được của các file — mà điều đó lại phụ thuộc vào lượng thông tin lặp lại bên trong chúng.

Nói cách khác, nếu bạn commit một file văn bản có nhiều dòng giống nhau, Git sẽ lưu nó nhỏ hơn nhiều so với một file nhị phân ngẫu nhiên có cùng kích thước.

Yếu tố thứ hai là việc Git dần dần chuyển các object file thành packfile — một định dạng nén hiệu quả hơn nữa, giúp loại bỏ phần dư thừa giữa các object với nhau. Nhờ đó, dung lượng lưu trữ tiếp tục được tối ưu theo thời gian khi bạn commit nhiều lần.

Thử nghiệm thực tế: Con số biết nói

Để có cái nhìn cụ thể, tác giả đã thực hiện một loạt thí nghiệm nhỏ, tất cả đều ở dạng "loose object" (chưa tạo packfile). Kết quả thu được như sau:

• 64.828 byte — sau lệnh git init (kho rỗng)
• 47.640 byte — commit 250 file nhỏ
• 17.145 byte — commit thay đổi 3 byte vào một file trong thư mục có 50 file
• 8.709 byte — commit thay đổi 3 byte trong repo chỉ có một file
• 297.873 byte — commit một file nhị phân 583.840 byte
• 1.622.188 byte — commit một file nguồn khổng lồ 16.415.223 byte

Overhead hàng KB cho những commit "tí hon"

Điểm đáng chú ý đầu tiên: với những commit cực nhỏ, bạn vẫn phải trả hàng chục KB chi phí cố định (overhead). Con số chính xác phụ thuộc vào kích thước của cây file/thư mục liên quan đến thay đổi đó.

Ví dụ, chỉ cần git init một repo rỗng, thư mục .git đã chiếm khoảng 64 KB. Sau khi commit 250 file nhỏ chứa chuỗi "foo", dung lượng tăng thêm gần 47 KB. Nhưng khi chỉ sửa 3 byte trong một file duy nhất của repo nhỏ, bạn chỉ tốn thêm khoảng 8-17 KB — phần lớn là overhead chứ không phải dữ liệu thật sự.

Với các commit nhỏ, phần lớn dung lượng đến từ "bộ khung" quản lý của Git, chứ không phải từ nội dung bạn thay đổi.

Lợi thế của file lớn: Nén cực kỳ hiệu quả

Điều thú vị hơn nằm ở các commit lớn. Với những commit chứa ít file nhưng dung lượng lớn, dữ liệu lưu trong .git chỉ chiếm từ 50% xuống còn 10% so với file gốc chưa nén.

Hãy xem hai ví dụ ấn tượng:

• File nhị phân 583 KB → chỉ tốn 297 KB trong .git (khoảng 51%)
• File nguồn văn bản 16,4 MB → chỉ tốn 1,6 MB trong .git (khoảng 10%!)

Đặc biệt, file nguồn văn bản khổng lồ kia — dù lên tới hơn 16 triệu byte — lại được nén xuống chỉ còn hơn 1,6 triệu byte. Đây là minh chứng rõ ràng cho hiệu quả của thuật toán nén zlib khi gặp dữ liệu văn bản có tính lặp lại cao.

Vì sao điều này quan trọng với lập trình viên Việt Nam?

Với các bạn làm việc trong các dự án có repository lớn, hiểu rõ cơ chế lưu trữ của Git giúp ích rất nhiều:

• Không nên lo lắng quá khi thấy thư mục .git phình to — phần lớn là overhead, không phải dữ liệu thật.
• Chạy git gc định kỳ để Git gộp các loose object thành packfile, tiết kiệm đáng kể dung lượng.
• Hạn chế commit file nhị phân lớn (như ảnh, video, file build) nếu không cần thiết, vì chúng khó nén và không thể xóa hoàn toàn khỏi lịch sử Git.
• Khi clone repo qua mạng chậm, hiểu về nén giúp bạn đặt kỳ vọng hợp lý hơn về thời gian tải.

Tóm lại, Git không chỉ thông minh trong việc quản lý phiên bản mà còn cực kỳ tiết kiệm dung lượng. Một commit có thể tốn vài KB overhead, nhưng đổi lại, dữ liệu nén của bạn được lưu trữ với hiệu suất đáng kinh ngạc — xứng đáng là công cụ không thể thiếu của mọi lập trình viên.