Một tính đặc hiệu của Git (và các hệ thống phân tán khác) so với các hệ thống tập trung là mỗi kho chứa toàn bộ lịch sử của dự án. Giả sử bạn tạo một tệp 100 Mb, sửa đổi nó 100 lần theo cách không nén tốt. Bạn sẽ kết thúc với một kho lưu trữ 10 Gb. Điều này có nghĩa là mỗi bản sao sẽ tải xuống 10 Gb dữ liệu, ăn 10 Gb dung lượng đĩa trên mỗi máy mà bạn đang tạo bản sao. Điều gì thậm chí còn bực bội hơn: bạn vẫn phải tải xuống 10 Gb dữ liệu này ngay cả khi bạn git rm các tệp lớn.
Đặt các tệp lớn trong một hệ thống riêng biệt như git-lfs cho phép bạn chỉ lưu trữ con trỏ tới mỗi phiên bản của tệp trong kho, do đó mỗi bản sao sẽ chỉ tải xuống một đoạn dữ liệu nhỏ cho mỗi bản sửa đổi. Thanh toán sẽ chỉ tải xuống phiên bản bạn đang sử dụng, nghĩa là 100 Mb trong ví dụ trên. Kết quả là, bạn sẽ sử dụng dung lượng đĩa trên máy chủ, nhưng tiết kiệm rất nhiều băng thông và không gian đĩa trên máy khách.
Ngoài ra, thuật toán được sử dụng bởi git gc (nội bộ, git repack) không phải lúc nào cũng hoạt động tốt với các tệp lớn. Các phiên bản gần đây của Git có tiến bộ trong lĩnh vực này và nó sẽ hoạt động khá tốt, nhưng sử dụng một kho lưu trữ lớn với các tệp lớn có thể khiến bạn gặp rắc rối (như không có đủ RAM để đóng gói lại kho lưu trữ của bạn).
Nguồn
2016-02-23 13:21:28
Bạn đã so sánh tốc độ kết nối chưa? – SOFe
Không. Tôi đang cố gắng tìm ra nguyên tắc. – Sanster
Với git-lfs, bản sao sẽ nhanh hơn. Thanh toán lâu hơn một chút, thời gian tải xuống các tệp được đặt trong lfs. Nhưng nếu bạn thực sự cần phải kiểm tra một số tập tin nhị phân, lfs là cách để làm. – Philippe