Hình ảnh nên được lưu trữ trong một kho git?

Đối với một nhóm phân phối sử dụng Git và Github làm điều khiển phiên bản, hình ảnh cũng có nên được lưu trữ trong kho git không?

Đối với hầu hết các phần, hình ảnh sẽ không được thay đổi. Thư mục chứa chúng sẽ chỉ tăng kích thước khi hình ảnh được thêm vào. Một mối quan tâm là thư mục hình ảnh có thể phát triển đến một kích thước lớn theo thời gian bằng cách kết hợp các hình ảnh lớn, hoặc chỉ rất nhiều trong số chúng.

Đây có được coi là một thực hành tốt nhất? Có những lựa chọn thay thế nào khác để chia sẻ các tệp nhị phân cần thiết trong các dự án mà một nhóm phân phối có thể dễ dàng truy cập?

Là hình ảnh của bạn ban đầu làm việc hoặc chúng có thể được phục hồi (đảm bảo?) Từ nơi khác? Họ có cần thiết để gửi một đơn vị phần mềm được xây dựng từ nguồn không? Nếu họ là bản gốc, họ cần sao lưu. Đặt chúng trong kiểm soát sửa đổi của bạn, nếu chúng không bao giờ thay đổi, hình phạt không gian giống như một bản sao lưu và chúng là nơi bạn cần chúng.

Họ có thể được chỉnh sửa để thay đổi sự xuất hiện của phần mềm, vô tình hay cố ý? Có - sau đó họ PHẢI được kiểm soát sửa đổi bằng cách nào đó, tại sao sử dụng một cách khác khi bạn đã có một giải pháp hoàn hảo. Tại sao lại giới thiệu kiểm soát phiên bản "sao chép và đổi tên" từ thời kỳ đen tối?

Tôi đã thấy tác phẩm nghệ thuật nguyên bản của toàn bộ dự án "gặp sự cố" khi ổ cứng MacBook của nhà thiết kế đồ họa chết, tất cả chỉ vì một người nào đó, với trí tuệ vô hạn, đã quyết định rằng "nhị phân không thuộc về kiểm soát vòng quay" và các nhà thiết kế đồ họa (ít nhất là cái này ) không có xu hướng tốt với các bản sao lưu.

Áp dụng tương tự cho bất kỳ và tất cả các tệp nhị phân phù hợp với các tiêu chí trên.

Lý do duy nhất không phải là không gian đĩa. Tôi sợ ở mức 100 đô la / terabyte, lý do đó là mặc hơi mỏng.

Tại sao các địa ngục không? :)

Lưu trữ nhị phân được coi là thực hành xấu, vâng, nhưng tôi không bao giờ lo lắng quá nhiều về hình ảnh.

Trường hợp xấu nhất, nếu bạn có hàng tấn, hãy lưu trữ chúng ở nơi khác hoặc sử dụng các phần bên ngoài hoặc phần mở rộng để hỗ trợ nhị phân. Và nếu hình ảnh sẽ không được thay đổi thường xuyên, thì vấn đề nằm ở đâu? Bạn sẽ không nhận được một đồng bằng lớn chất béo. Và nếu chúng bị xóa theo thời gian, chỉ có máy chủ của bạn chịu một chút lưu trữ lịch sử, nhưng khách hàng sẽ không thấy điều gì.

Theo tôi, bạn không nên lo lắng về điều đó - miễn là bạn không lưu trữ GB trong số đó.

Mặc dù vậy, những gì bạn có thể làm là chỉ lưu trữ hình ảnh "nguồn": SVG, macro LaTeX, v.v ... và có những hình ảnh cuối cùng được tạo bởi hệ thống xây dựng của bạn. Điều đó có lẽ còn tốt hơn, nếu bạn có thể. Nếu không, thì đừng bận tâm.

(Tất cả những gì đang nói, Git tỏa sáng cho các tệp văn bản, nhưng không phải là VCS tốt nhất cho hình ảnh. Hãy cho chúng tôi thêm ngữ cảnh và số liệu nếu bạn có thể)

Để biết thêm thông tin, bạn có thể muốn xem các Hỏi & Đáp sau:

• Lưu trữ tệp hình ảnh trong SubVersion / Git
• Git vs SVN với các tệp không phải là văn bản
• Quản lý tệp nhị phân lớn với mô đun con Git và Git

Câu hỏi này khá cũ nhưng đây là một câu hỏi phổ biến xuất hiện khi giao dịch với Git và có một số tiến bộ về các giải pháp hiện đại để lưu trữ các tệp lớn trong repo Git kể từ câu trả lời cuối cùng.

Để lưu trữ các tệp lớn trong Git, có các dự án sau:

• git-annex - Điều này đã xuất hiện được một lúc nhưng thật ra nó rất phức tạp.
• git-media - Không có kinh nghiệm cá nhân với cái này. Có vẻ khá phức tạp là tốt.
• git-fit - Một nỗ lực để tạo một plugin đơn giản hơn. Yêu cầu lưu trữ S3. Mặc dù tôi đánh giá cao sự đơn giản mà mối quan tâm chính của tôi với plugin là nó khá lạ và được duy trì bởi 1 cá nhân (tiết lộ đầy đủ, tôi là người duy nhất khác vào lúc này và đó là một vấn đề không quan trọng).
• git-lfs - Trong khi tôi chưa sử dụng rộng rãi thì nó dường như là chén thánh. Nó được hỗ trợ bởi Github và có sẵn trên tất cả các repos của họ kể từ tháng 10 năm 2015 và đặt sự phức tạp của việc quản lý tệp lên trang web lưu trữ repos của bạn. Nhược điểm duy nhất là điều này khá mới, vì vậy ngoài Github không có nhiều hỗ trợ, mặc dù Gitlab cũng có hỗ trợ , cũng như Gitea và Bitbucket đã ám chỉ hỗ trợ trong tương lai .

TLDR: nếu bạn có thể, hãy sử dụng git-lfs để lưu trữ hình ảnh hoặc các tệp nhị phân khác trong git.

Toàn bộ "không lưu trữ nhị phân trong kiểm soát nguồn" được đặt ra vì một lý do cụ thể: Nếu bạn có mã nguồn biên dịch, đừng lưu trữ phần biên dịch thực tế, mà chỉ là mã nguồn. Hình ảnh và tài sản hình ảnh không có "nguồn", vì vậy chúng phải được theo dõi trong kiểm soát phiên bản.

Tôi tin rằng cách được đề xuất với Git là sử dụng một mô-đun phụ (được giới thiệu trong Git 1.5.3) về cơ bản là một kho lưu trữ riêng được liên kết với mô-đun chính. Bạn lưu trữ hình ảnh của bạn (và các tài sản nhị phân khác) trong mô-đun phụ. Điều này sau đó có thể được kiểm tra với kho lưu trữ chính hoặc bên trái, tùy thuộc vào những gì được yêu cầu.

Từ http://book.git-scm.com/5_submodules.html

"Hỗ trợ mô hình con của Git cho phép một kho lưu trữ, như một thư mục con, một kiểm tra của một dự án bên ngoài. Các mô hình con duy trì danh tính của riêng chúng; superproject ") có thể dễ dàng sao chép tất cả các mô hình con trong cùng một phiên bản. Kiểm tra một phần của siêu dự án là có thể: bạn có thể bảo Git sao chép không, một số hoặc tất cả các mô hình con."

Ngoài ra, kích thước không phải là một vấn đề quan trọng nếu hình ảnh không thay đổi thường xuyên. Bạn cũng có thể chạy các lệnh để cắt / giảm kích thước, chẳng hạn như:

git gc
git gc-aggressive
git prune

Có .

Hãy nói rằng bạn phát hành phiên bản phần mềm 1.0. Đối với phiên bản 2.0, bạn quyết định làm lại tất cả các hình ảnh có bóng. Vì vậy, bạn làm điều này, và phát hành 2.0. Sau đó, một số khách hàng đang sử dụng 1.0 và không thể nâng cấp lên 2.0 quyết định họ muốn chương trình này bằng ngôn ngữ khác. Họ cung cấp cho bạn $ 1G để làm điều đó, vì vậy bạn nói chắc chắn. Nhưng ở một nền văn hóa khác, một số hình ảnh của bạn không có ý nghĩa, vì vậy bạn phải thay đổi chúng ...

Nếu bạn sẽ giữ hình ảnh của mình trong kiểm soát nguồn, điều này thật dễ dàng, dựa trên 1.0 bạn thực hiện thay đổi cho hình ảnh (trong số những thứ khác), xây dựng, phát hành. Nếu bạn không có những thứ này trong kiểm soát nguồn, bạn sẽ có một thời gian khó khăn hơn nhiều, vì bạn sẽ phải tìm những hình ảnh cũ, thay đổi chúng, và sau đó xây dựng.

Nếu nó là một phần của Dự án, nó phải nằm trong VCS . Làm thế nào để đạt được điều này tốt nhất có thể phụ thuộc vào VCS hoặc cách bạn tổ chức Dự án. Có thể là một repo cho các nhà thiết kế và chỉ các kết quả trong repo của coder hoặc chỉ là 'Nguồn hình ảnh' (tôi đã từng có một dự án chỉ với một tệp .svg và các hình ảnh được tạo thông qua make / inscape cli).

Nhưng, nếu một VCS không thể xử lý điều đó, hoặc trở nên không thể tin được, tôi sẽ nói, đó không phải là công cụ phù hợp cho công việc của bạn.

Cho đến nay, tôi không gặp vấn đề gì với việc đưa số lượng đồ họa 'thông thường' (mockup, khái niệm và đồ họa trang) cho các dự án web trong git.

Bạn nên lưu trữ hình ảnh của bạn trong SCM: có. Không nghi ngờ gì.

Bạn nên lưu trữ hình ảnh của bạn trong git: điều này trở nên khó khăn hơn.

git rất tốt với các tệp văn bản, nhưng bản chất của nó không quá nóng với các tệp nhị phân. Bạn sẽ gặp vấn đề với kích thước của dữ liệu được truyền khi bạn sao chép hoặc đẩy, các thư mục .git của bạn sẽ phát triển và bạn có thể gặp rắc rối với việc hợp nhất (ví dụ: làm thế nào để bạn hợp nhất 2 hình ảnh!)

Một câu trả lời là sử dụng các mô hình con, vì điều này có nghĩa là liên kết giữa dự án của bạn và hình ảnh sẽ yếu hơn - vì vậy bạn sẽ không phải quản lý hình ảnh như thể chúng là một phần của nguồn của bạn, nhưng vẫn giữ chúng được kiểm soát và không có lo lắng với việc phân nhánh chúng - giả sử dự án con chỉ là kho lưu trữ dữ liệu 'phẳng' mà không trải qua cùng một giai đoạn trong quá trình phát triển thông thường.

Câu trả lời khác là đưa chúng vào một dự án khác, không bao giờ phân nhánh nó và đảm bảo rằng tất cả những người cam kết với dự án đó sẽ đẩy nó ngược dòng ngay lập tức - không bao giờ để 2 người thay đổi cùng một phiên bản của tệp - bạn sẽ thấy điều này là khó khăn nhất khía cạnh như git không được thiết kế cho một quy trình công việc không phân tán như vậy. Bạn sẽ phải sử dụng các phương thức giao tiếp lỗi thời để tuân theo quy tắc này.

Câu trả lời thứ ba là đưa chúng vào một SCM khác hoàn toàn phù hợp hơn để làm việc với hình ảnh.

Thêm vào câu trả lời của @ haylem, lưu ý rằng kích thước đóng vai trò lớn trong việc này. Tùy thuộc vào VCS, nó có thể không hoạt động tốt với hàng tấn hình ảnh. Khi nhân bản hoặc đẩy lớn bắt đầu mất cả đêm thì thực sự đã quá muộn vì tất cả các hình ảnh đã có trong kho lưu trữ của bạn.

Lập kế hoạch cho hình ảnh lớn và tăng trưởng trong tương lai. Bạn không muốn có hai năm tham gia vào dự án này và có một "ôi thôi, có lẽ repo là một chút quá lớn."

Tôi chắc chắn đồng ý rằng việc lưu trữ chúng về mặt kỹ thuật và kinh tế là khả thi. Câu hỏi tôi muốn là "những hình ảnh này là một phần của sản phẩm vận chuyển hay một phần nội dung của sản phẩm vận chuyển?" Không phải là bạn không thể lưu trữ nội dung trong GIT (hoặc bất kỳ VCS nào khác) mà đó là một vấn đề riêng cho một VCS riêng.