"Nó phụ thuộc." Để theo dõi phát triển bình thường, không. Tuy nhiên, đối với việc triển khai đám mây và DevOps, điều này thường thuận tiện hoặc thậm chí là bắt buộc.
Hầu hết thời gian,
@ptyx là chính xác . Thật vậy, "không" của anh ta có thể được nói rõ hơn một chút. Một cái gì đó như "Không. Không! OMG NO! "
Tại sao không lưu trữ tài sản nén hoặc nén trong hệ thống kiểm soát nguồn như Git?
Chúng có thể được phục hồi gần như tầm thường bởi quá trình xây dựng của bạn một cách nhanh chóng từ mã nguồn. Lưu trữ tài sản nén về cơ bản là lưu trữ cùng một nội dung logic hai lần. Nó vi phạm nguyên tắc "không lặp lại chính mình" (còn gọi là DRY ).
Một lý do ít triết lý hơn nhưng thực tế hơn là các tài sản được tối giản hóa / tối ưu hóa có khả năng nén rất kém khi được lưu trữ trong Git. Các hệ thống kiểm soát nguồn hoạt động bằng cách nhận ra các thay đổi ("deltas") giữa các phiên bản khác nhau của mỗi tệp được lưu trữ. Để làm điều đó, họ "khác biệt" tệp mới nhất với phiên bản trước đó và sử dụng các đồng bằng này để tránh lưu trữ một bản sao hoàn chỉnh của mọi phiên bản của tệp. Nhưng các phép biến đổi được thực hiện trong bước minify / tối ưu hóa thường loại bỏ các điểm tương đồng và điểm tham chiếu mà thuật toán diff / delta sử dụng. Ví dụ tầm thường nhất là loại bỏ ngắt dòng và khoảng trắng khác; tài sản kết quả thường chỉ là một dòng dài. Nhiều phần của quy trình xây dựng Web - các công cụ như Babel , UglifyJS , Browserify ,Ít hơn và Sass / SCSS - chuyển đổi mạnh mẽ các tài sản. Sản lượng của họ là nhiễu loạn; thay đổi đầu vào nhỏ có thể dẫn đến những thay đổi lớn trong đầu ra. Kết quả là, thuật toán diff sẽ thường tin rằng nó nhìn thấy gần như một tệp hoàn toàn khác nhau mỗi lần. Kết quả là kho của bạn sẽ phát triển nhanh hơn. Đĩa của bạn có thể đủ lớn và mạng của bạn đủ nhanh, đó không phải là vấn đề lớn, đặc biệt là nếu có một giá trị để lưu trữ tài sản được tối ưu hóa / tối ưu hóa hai lần - mặc dù dựa trên điểm 1, các bản sao bổ sung có thể chỉ là vô nghĩa 100% sưng lên.
Tuy nhiên, có một ngoại lệ lớn: triển khai DevOps / đám mây. Một số nhà cung cấp đám mây và nhóm DevOps sử dụng Git và tương tự không chỉ để theo dõi các bản cập nhật phát triển mà còn tích cực triển khai các ứng dụng và tài sản của họ để kiểm tra và sản xuất máy chủ. Trong vai trò này, khả năng của Git để xác định hiệu quả "tập tin nào đã thay đổi?" cũng quan trọng như khả năng chi tiết hơn của nó để xác định "điều gì đã thay đổi trong mỗi tệp?" Nếu Git phải thực hiện một bản sao tệp gần như đầy đủ cho các tài sản được tối thiểu hóa / tối ưu hóa, sẽ mất nhiều thời gian hơn một chút so với trước đây, nhưng không có vấn đề gì lớn vì nó vẫn hoạt động rất tốt giúp tránh một bản sao của "mọi tệp trong dự án" trên mỗi chu kỳ triển khai.
Nếu bạn đang sử dụng Git làm công cụ triển khai, việc lưu trữ các tài sản được tối ưu hóa / tối ưu hóa trong Git có thể chuyển từ "không!" để mong muốn. Thật vậy, nó có thể được yêu cầu, giả sử nếu bạn thiếu các cơ hội xây dựng / xử lý hậu kỳ mạnh mẽ trên các máy chủ / dịch vụ mà bạn triển khai. (Cách phân đoạn các tài sản phát triển và triển khai trong trường hợp đó là một loại giun riêng biệt. Cho đến nay, người ta biết rằng nó có thể được quản lý theo nhiều cách, bao gồm một kho lưu trữ thống nhất, nhiều nhánh, phân vùng hoặc thậm chí nhiều kho lưu trữ chồng chéo. )
/dev/null.