Tương lai của tệp dung lượng lớn trong Git chính là bản thân Git

• Dự án Git gần đây đã chính thức bắt đầu trực tiếp giải quyết vấn đề quản lý tệp dung lượng lớn
• Git LFS là một giải pháp tình thế, gây ra nhiều chi phí và sự phụ thuộc vào nhà cung cấp cho người dùng
• Gần đây, với tính năng partial clone, chỉ riêng Git cũng đã có thể thay thế phần lớn vai trò của LFS
• Trong tương lai, một giải pháp mới tên là large object promisor cũng đang được chuẩn bị để tích hợp vào Git chính thức
• Những thay đổi này cho thấy lời giải cuối cùng cho việc quản lý tệp dung lượng lớn sẽ quy về chính Git, thay vì các phần mở rộng bên ngoài

---

Vấn đề tệp dung lượng lớn của Git và những thay đổi đang diễn ra

• Nếu có một "khắc tinh" lớn nhất của Git, thì đó chính là tệp dung lượng lớn
• Tệp dung lượng lớn làm phình to kho lưu trữ Git, làm chậm git clone, và gây ảnh hưởng xấu tới hầu hết các môi trường hosting

Sự xuất hiện và giới hạn của Git LFS

• Năm 2015, GitHub đã phát hành Git LFS để lách qua vấn đề tệp dung lượng lớn
• Tuy nhiên, bản thân Git LFS lại làm phát sinh thêm độ phức tạp và chi phí lưu trữ

• Cộng đồng Git từ lâu đã âm thầm suy nghĩ về bài toán cốt lõi của tệp dung lượng lớn, và trong các bản phát hành chính thức gần đây của Git, một hướng đi mới để quản lý tệp dung lượng lớn mà không cần LFS đã được đưa ra

Cách có thể áp dụng ngay hôm nay: thay Git LFS bằng partial clone

• Nguyên lý của partial clone

  • Git LFS: tệp dung lượng lớn được đặt bên ngoài kho lưu trữ, và chỉ tải về những tệp cần thiết để làm việc
  • Git partial clone (được giới thiệu năm 2017):
    • Dùng tùy chọn --filter để sao chép mà loại trừ các blob lớn hơn kích thước mong muốn
    • Chỉ khi cần mới tải chính tệp dung lượng lớn đó từ máy chủ
      > Khi dùng partial clone, bạn không cần tải trước [các tài sản nhị phân dung lượng lớn] trong lúc Clone và Fetch, nhờ đó giảm thời gian tải xuống và dung lượng đĩa sử dụng
      > - Partial Clone Design Notes, git-scm.com

• Điểm chung giữa partial clone và LFS

  • 1. Giảm tối thiểu dung lượng checkout: chỉ lấy phiên bản mới nhất và bỏ qua toàn bộ lịch sử tệp
  • 2. Sao chép nhanh: không phải truyền tệp dung lượng lớn nên tốc độ clone nhanh hơn
  • 3. Thiết lập nhanh: khác với shallow clone, vẫn có thể truy cập toàn bộ lịch sử dự án

• Ví dụ sử dụng partial clone

  • Ví dụ thực tế về tốc độ sao chép repo và dung lượng đĩa khi một repo có nhiều lịch sử của các tệp PNG lớn:
    • clone thông thường mất gần 4 phút, chiếm 1.3GB
    • với partial clone và giới hạn blob 100KB, chỉ mất 6 giây để clone, chiếm 49MB
    • cải thiện 97% tốc độ sao chép và giảm 96% kích thước checkout so với bản gốc

• Giới hạn của partial clone

  • Khi cần đến dữ liệu đã bị lọc (ví dụ: git diff, git blame, git checkout), Git sẽ yêu cầu tệp từ máy chủ
  • Đây là đặc tính giống hệt Git LFS
  • Trong công việc thực tế, hiếm khi cần chạy blame trên tệp nhị phân

Các vấn đề của Git LFS

• Mức độ phụ thuộc nhà cung cấp cao: bản triển khai của GitHub chỉ hỗ trợ máy chủ riêng của họ, kéo theo phí và sự phụ thuộc
• Vấn đề chi phí: lưu 50GB trên GitHub LFS tốn $40/năm, còn Amazon S3 là $13
• Khó quay lại: một khi đã chuyển sang LFS thì không thể khôi phục nguyên trạng nếu không viết lại lịch sử
• Chi phí thiết lập liên tục: mọi cộng tác viên đều phải cài LFS; nếu không cài thì thay vì tệp thật sẽ nhận được tệp metadata, dễ gây nhầm lẫn

Triển vọng sắp tới: Large Object Promisor

• Tệp dung lượng lớn cũng gây ra vấn đề chi phí cho các nền tảng hosting như GitHub và GitLab
• Git LFS giảm chi phí máy chủ bằng cách offload tệp dung lượng lớn sang CDN

• Large Object Promisor là gì?

  • Đầu năm nay, Git đã chính thức merge một tính năng tên là large object promisor
  • Tính năng này giảm tải lưu trữ phía máy chủ tương tự LFS, nhưng cắt giảm đáng kể độ phức tạp phía người dùng
    > Nỗ lực này nhằm cải thiện công việc ở phía máy chủ, đặc biệt là với các blob lớn đã được nén ở dạng nhị phân
    > Đây là một giải pháp thay thế cho Git LFS
    > – Large Object Promisors, git-scm.com

• Cơ chế hoạt động

  • 1. Người dùng push tệp dung lượng lớn lên Git host
  • 2. Host xử lý offload các tệp dung lượng lớn sang promisor ở backend
  • 3. Khi clone, Git host cung cấp thông tin promisor cho client
  • 4. Khi cần, client sẽ tự động nhận tệp dung lượng lớn từ promisor đó

• Tình hình triển khai hiện tại và các thách thức

  • Large object promisor vẫn đang trong quá trình phát triển, và đến tháng 3/2025 một phần mã đã được merge vào Git
  • Các triển khai bổ sung và những vấn đề chưa được giải quyết đang tiếp tục được thảo luận tại GitLab và những nơi khác
  • Vẫn cần thêm thời gian trước khi được áp dụng rộng rãi
  • Trong thời gian trước mắt, việc lưu trữ tệp dung lượng lớn vẫn khó tránh khỏi phụ thuộc vào Git LFS
  • Khi promisor được phổ biến, GitHub cũng được kỳ vọng sẽ cho phép tải lên các tệp vượt quá 100MB

Kết luận: Tương lai tệp dung lượng lớn của Git là Git

• Dự án Git đang không ngừng suy nghĩ về vấn đề tệp dung lượng lớn thay cho bạn
• Hiện tại, việc dùng Git LFS vẫn còn cần thiết
• Tuy nhiên, khi partial clone và large object promisors tiếp tục phát triển, Git LFS sẽ dần trở nên không còn cần thiết, và chẳng bao lâu nữa chúng ta có thể dễ dàng quản lý tệp dung lượng lớn chỉ bằng Git
• Trong tương lai, rào cản cuối cùng đối với việc dùng tệp dung lượng lớn có lẽ chỉ còn là ý nghĩ muốn đưa cả thư viện MP3 vào Git