Tại sao bạn nên kiểm tra file nhị phân trong Git?

Giới thiệu

Trong môi trường phát triển phần mềm, việc quản lý mã nguồn là rất quan trọng. Là một kiến trúc sư phần mềm, tôi đã bắt đầu một cuộc khảo sát về không gian lưu trữ mà các file không cần thiết chiếm dụng trong kho Git của công ty. Không phải là các vấn đề như mật khẩu hay khóa API — đó là những điều hiển nhiên. Mà tôi đang nói đến các file nhị phân như DLL, file .so, các file thực thi và thậm chí các thư viện như jquery.js được commit trực tiếp vào kho.

Trước khi thực hiện công việc thực tiễn, tôi cần xây dựng một cơ sở kỹ thuật để biện minh cho nỗ lực này. Bài viết này sẽ tài liệu hóa cuộc nghiên cứu mà tôi đã thực hiện để làm nền tảng cho quyết định này — và có thể hữu ích cho những người gặp phải tình huống tương tự.

Có nên thực hiện việc kiểm tra không?

Trong hầu hết các trường hợp, câu trả lời là có — nhưng có những sắc thái quan trọng.

Nỗ lực xác định và loại bỏ các file nhị phân có thể mang lại lợi ích lớn về hiệu suất, chi phí và khả năng bảo trì. Tuy nhiên, có những kịch bản cụ thể mà việc phiên bản hóa nhị phân có thể chấp nhận được hoặc thậm chí cần thiết.

Hiệu suất và Tính hiệu quả

Tác động kỹ thuật:

Mỗi phiên bản của một file nhị phân tạo ra một blob mới đầy đủ trong lịch sử.
Git không thực hiện nén delta hiệu quả với các file nhị phân.
Các thao tác như (clone, fetch, push) sẽ trở nên chậm hơn tương ứng.

Ví dụ có thể đo lường:

File nhị phân 50MB được phiên bản hóa 20 lần → ~1GB thêm vào lịch sử.
git clone có thể mất 30 giây có thể kéo dài thành vài phút.
Đối với các nhóm từ 20 người trở lên, điều này có thể mất hàng giờ thời gian mỗi tháng.

Các trường hợp đã được tài liệu hóa: Kho lưu trữ có các file nhị phân trong lịch sử thường gặp phải sự suy giảm đáng kể. Một kho lưu trữ microservice với các JAR phụ thuộc được commit có thể dễ dàng đạt tới 800MB, trong đó 600MB là từ các file nhị phân — ảnh hưởng đến thời gian clone một cách không tương xứng.

Chi phí Lưu trữ

Tác động trực tiếp:

Bitbucket Cloud: giới hạn 4GB mỗi kho (trong các gói miễn phí).
Các máy chủ tự lưu trữ: chi phí lưu trữ tăng trưởng không giới hạn.
CI/CD: việc checkout chậm hơn làm tăng thời gian và chi phí cho các build.

Ví dụ thực tế:

Một kho lưu trữ với 500MB các file nhị phân trong lịch sử có thể tốn thêm 10-15 phút cho mỗi build trong CI/CD.
Với 100 build/ngày = ~25 giờ/tháng thời gian máy tính bị lãng phí.

Khả năng Bảo trì

Vấn đề cụ thể:

Các file nhị phân không tạo ra diffs dễ đọc cho việc xem xét mã.
Xung đột là không thể khôi phục (xung đột merge nhị phân = chọn một phiên bản).
Thư viện bên thứ ba (jquery.js) nên được lấy từ các trình quản lý gói.

Khi nào việc sử dụng nhị phân trong Git có thể chấp nhận được

Các kịch bản hợp lệ:

File nhị phân nhỏ (<100KB) và hiếm khi được chỉnh sửa.
Bootstrap thiết yếu: công cụ tối thiểu cho việc thiết lập dự án ban đầu.
Tuân thủ quy định: các artefact không thay đổi cần thiết cho kiểm toán (tài chính, sức khỏe).
Dự án cô lập: ít cộng tác viên, tần suất thay đổi thấp.

Các yếu tố cần cân nhắc:

Các kho lưu trữ nhỏ (<50MB tổng) với đội ngũ nhỏ (<5 người): tác động có thể là không đáng kể.
Chi phí di chuyển so với lợi ích: đánh giá xem nỗ lực có xứng đáng với lợi ích hay không.

Các giải pháp thay thế và những giới hạn của chúng

Git LFS (Large File Storage)

Phù hợp cho: tài sản truyền thông, datasets, các file lớn không thể tránh khỏi.

Giới hạn:

Cần cấu hình bổ sung trên máy chủ.
Thêm độ phức tạp vào quy trình làm việc (git lfs install, git lfs track, git lfs pull).
Không phải tất cả các Bitbucket Cloud đều hỗ trợ không giới hạn.
Nhóm cần được đào tạo quy trình làm việc mới.

Trình quản lý gói

Khuyến nghị cho: các phụ thuộc bên thứ ba.

JavaScript: npm, yarn, pnpm.
Java: maven, gradle.
Python: pip, poetry.
C++: conan, vcpkg.

Kho lưu trữ Artefact

Phù hợp cho: các build, phát hành, thư viện nội bộ.

Artifactory, Nexus, Google Artifact Registry.
Tích hợp tự nhiên với CI/CD.
Kiểm soát phiên bản, bảo mật và kiểm toán.
Lợi thế so với Git LFS: tốt hơn cho các pipeline tự động hóa.

Cách tiếp cận phổ biến: Di chuyển các file nhị phân từ các build sang các kho lưu trữ chuyên dụng (như Nexus) và cấu hình các công cụ build (Maven, Gradle) để tự động tải xuống có thể loại bỏ hàng trăm MB từ các kho lưu trữ quan trọng.

Kho lưu trữ Container

Phù hợp cho: các file nhị phân đóng gói trong hình ảnh Docker.

Docker Hub, Google Container Registry, Amazon ECR.
Phiên bản qua tag hình ảnh.
Lý tưởng cho các triển khai container hóa.

Cách xác định các file có vấn đề

Lệnh để liệt kê các blob lớn nhất:

Copy

git rev-list --objects --all |
  git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' |
  awk '/^blob/ {print $3, $2, $4}' |
  sort -rn |
  head -20

Công cụ chuyên dụng:

Copy

# Phân tích đầy đủ kho lưu trữ
git-sizer --verbose

# Làm sạch an toàn lịch sử
git filter-repo --strip-blobs-bigger-than 10M
# hoặc
bfg --strip-blobs-bigger-than 10M

Các chỉ số cho quyết định

Trước khi bắt đầu việc kiểm tra, hãy đo lường:

Cơ sở hiện tại:

Copy

# Kích thước của kho lưu trữ
du -sh .git

# Thời gian clone
time git clone <repo-url>

# Các file lớn nhất trong lịch sử
git-sizer --verbose | grep "Maximum blob size"

Sau khi làm sạch, so sánh:

Giảm kích thước (%)
Giảm thời gian clone (giây)
Tác động đến thời gian CI/CD.

ROI dự kiến:

Các kho lưu trữ >1GB: lợi ích đáng kể cho các đội ngũ trung bình/lớn.
Các kho lưu trữ <100MB: đánh giá chi phí so với lợi ích từng trường hợp một.

Các khuyến nghị thực tiễn

Hành động ngay lập tức:

Cấu hình .gitignore phù hợp:

Copy

# Các artefact build
*.dll
*.so
*.exe
*.o
target/
dist/
build/

# Các phụ thuộc
node_modules/
vendor/

Kiểm tra với git-sizer:

Copy

git-sizer --verbose

Triển khai pre-commit hooks:

Copy

# Ví dụ: chặn các file >10MB
#!/bin/bash
MAX_SIZE=10485760
for file in $(git diff --cached --name-only); do
  size=$(wc -c < "$file")
  if [ $size -gt $MAX_SIZE ]; then
    echo "Lỗi: $file vượt quá 10MB"
    exit 1
  fi
done

Dài hạn:

Xác định chính sách rõ ràng về phiên bản hóa.
Di chuyển các file nhị phân sang giải pháp phù hợp (LFS, Artifactory, v.v.).
Tài liệu trong README.md cách lấy các phụ thuộc.
Đo lường tác động liên tục.
Đồng bộ với các yêu cầu tuân thủ khi áp dụng.

Tài liệu tham khảo có thể kiểm tra

Tài liệu chính thức

Git SCM - Git Attributes
https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes
Giải thích cách Git xử lý các file nhị phân và các giới hạn của diff/merge.

Atlassian - Hướng dẫn Git LFS
https://www.atlassian.com/git/tutorials/git-lfs
Hướng dẫn chính thức về khi nào và làm thế nào để sử dụng Git LFS trong Bitbucket.

GitHub - Làm việc với các file lớn
https://docs.github.com/en/repositories/working-with-files/managing-large-files
Các thực tiễn tốt nhất cho các file lớn.

Sách tham khảo

Pro Git (Scott Chacon & Ben Straub)
https://git-scm.com/book
Các chương liên quan: 2.2 (Cơ bản về Git), 10.2 (Nội bộ Git - Objects).

Version Control with Git (Jon Loeliger & Matthew McCullough)
O'Reilly Media
Đề cập đến kỹ thuật về lưu trữ đối tượng và hiệu suất.

Tài liệu học thuật

"Tại sao Google lưu trữ hàng tỷ dòng mã trong một kho lưu trữ duy nhất"
Communications of ACM, Vol. 59 No. 7, Pages 78-87 (2016)
https://dl.acm.org/doi/10.1145/2854146
Chiến lược monorepo và quản lý tài sản quy mô lớn.

Kết luận

Kiểm tra hầu như luôn có lợi, nhưng giá trị thực sự nằm ở việc đo lường tác động cho ngữ cảnh cụ thể của bạn:

Các kịch bản nơi điều này rất quan trọng:

Kho lưu trữ được sử dụng bởi các nhóm lớn (>10 người).
Lưu trữ >500MB với sự tăng trưởng liên tục.
Thời gian clone >2 phút.
Pipelines CI/CD chậm.

Các kịch bản cần xem xét chi phí-lợi ích:

Các kho lưu trữ nhỏ (<100MB) và cô lập.
Nhóm nhỏ (<5 người).
Các file nhị phân cần thiết cho tuân thủ.
Tần suất thao tác Git thấp.

Cách tiếp cận khuyến nghị:

Thí điểm: chọn 1-2 kho lưu trữ quan trọng.
Đo lường: thu thập các chỉ số trước/sau.
Tính toán ROI: thời gian tiết kiệm × số lượng nhà phát triển.
Quyết định: mở rộng chính sách dựa trên dữ liệu cụ thể.

Bước tiếp theo: Cơ sở lý thuyết này sẽ được bổ sung bằng dữ liệu thực tế từ cuộc khảo sát đang diễn ra. Thử nghiệm trên kho lưu trữ thí điểm sẽ cho phép xác thực các giả thuyết được nêu ra ở đây và định lượng lợi ích cụ thể cho ngữ cảnh của chúng tôi.

Kinh nghiệm của bạn

Bạn đã trải qua tình huống tương tự? Bạn đang xem xét việc kiểm tra trong công ty của mình? Hãy chia sẻ trong phần bình luận!

Tại sao bạn nên kiểm tra file nhị phân trong Git?

Giới thiệu

Có nên thực hiện việc kiểm tra không?

Hiệu suất và Tính hiệu quả

Chi phí Lưu trữ

Khả năng Bảo trì

Khi nào việc sử dụng nhị phân trong Git có thể chấp nhận được

Các kịch bản hợp lệ:

Các yếu tố cần cân nhắc:

Các giải pháp thay thế và những giới hạn của chúng

Git LFS (Large File Storage)

Trình quản lý gói

Kho lưu trữ Artefact

Kho lưu trữ Container

Cách xác định các file có vấn đề

Lệnh để liệt kê các blob lớn nhất:

Công cụ chuyên dụng:

Các chỉ số cho quyết định

Trước khi bắt đầu việc kiểm tra, hãy đo lường:

Các khuyến nghị thực tiễn

Hành động ngay lập tức:

Dài hạn:

Tài liệu tham khảo có thể kiểm tra

Tài liệu chính thức

Sách tham khảo

Tài liệu học thuật

Kết luận

Các kịch bản nơi điều này rất quan trọng:

Các kịch bản cần xem xét chi phí-lợi ích:

Cách tiếp cận khuyến nghị:

Kinh nghiệm của bạn

Bình luận