Чи слід зберігати зображення у сховищі git?

Якщо розподілена команда, яка використовує Git та Github як контроль версій, чи повинні також зберігатись зображення у сховищі git?

Здебільшого зображення не змінюватимуться. Папка, що містить їх, буде збільшуватися лише в міру додавання зображень. Занепокоєння полягає в тому, що папка зображень може з часом збільшитися до великих розмірів за рахунок комбінації великих зображень або просто багатьох із них.

Це вважається найкращою практикою? Які ще існують альтернативи для спільного використання бінарних файлів, необхідних для проектів, до яких розповсюджена команда може легко отримати доступ?

Ваші зображення оригінальні, чи їх можна відновити (гарантувати?) З інших місць? Чи потрібні вони для доставки програмного блоку, побудованого з джерела? Якщо вони оригінальні, вони потребують резервного копіювання. Покладіть їх на свій контроль перегляду, якщо вони ніколи не змінюються, пробіл у розмірі - це те саме, що резервне копіювання, і вони знаходяться там, де вам потрібно.

Чи можна їх редагувати, щоб змінити зовнішній вигляд програмного забезпечення випадково чи навмисно? Так - тоді вони ОБ'ЄДНАТЬ якось контролювати ревізію, навіщо використовувати інший спосіб, коли у вас вже є ідеальне рішення. Навіщо вводити "копіювати і перейменувати" контроль версій з темних віків?

Я бачив, як оригінальний художній твір усього проекту став "пуфом", коли жорсткий диск MacBook графічного дизайнера помер, все тому, що хтось з нескінченною мудрістю вирішив, що "бінарні файли не належать до контролю оборотів", а також графічні дизайнери (принаймні, цей ) не прагнуть бути гарними з резервними копіями.

Те саме стосується будь-яких бінарних файлів, які відповідають вищевказаним критеріям.

Єдина причина цього - це місце на диску. Я боюся, що за 100 доларів / терабайт, це виправдання носить трохи тонкий.

Чому, чорт, не? :)

Зберігання бінарних файлів вважається поганою практикою, так, але я ніколи не надто хвилювався щодо зображень.

Найгірший випадок, якщо у вас є тони, зберігайте їх десь в іншому місці або використовуйте зовнішні або розширення для бінарної підтримки. І якщо зображення не будуть змінені так часто, то де проблема? Ви не отримаєте великої жирової дельти. І якщо вони будуть видалені з часом, зберігання історії лише страждає від вашого сервера, але клієнти нічого не побачать.

На мою думку, ви не повинні турбуватися з цього приводу - якщо ви не зберігаєте GB-файли.

Що ви можете зробити, це лише зберігати "вихідні" зображення: SVG, LaTeX макроси тощо ... та мати остаточні зображення, створені вашою системою збирання. Це, мабуть, навіть краще, якщо зможете. Якщо ні, то не турбуйтеся.

(Все, що говориться, Git світить для текстових файлів, але це не найкращий VCS для зображень. Надайте нам більше контексту та показників, якщо зможете)

Для отримання додаткової інформації ви можете переглянути ці запитання:

• Зберігання файлів зображень у SubVersion / Git
• Git vs SVN з нетекстовими файлами
• Управління великими бінарними файлами за допомогою Git та Git-підмодуля

Це запитання досить старе, але це поширене питання, яке виникає при роботі з Git, і є певний прогрес у сучасних рішеннях для зберігання великих файлів у репортажі Git з часу останньої відповіді.

Для зберігання великих файлів у Git є такі проекти:

• git-annex - Це існує вже деякий час, але, чесно кажучи, складність стає на шляху.
• git-media - Немає особистого досвіду з цим. Здається, також досить складно.
• git-fit - спроба створити більш простий плагін. Потрібно зберігання S3. Хоча я ціную простоту, головна моя турбота про плагін - це те, що вона є досить невідомою та підтримується 1 особою (повне розкриття інформації, я є єдиним іншим виконавцем на даний момент, і це стосувалося тривіальної проблеми).
• git-lfs - Хоча я не використовував цього широко, схоже, це святий грааль. Він підтримується Github і доступний для всіх їхніх репортажів з жовтня 2015 року, а також ускладнює керування файлами на сайті, де зберігаються ваші репости. Мінус лише в тому, що це досить нове, тому поза межами Github не існує великої підтримки, хоча Gitlab також має підтримку , як і Gitea , і Bitbucket посилається на підтримку в майбутньому .

TLDR: якщо ви можете, використовуйте git-lfs для зберігання зображень або інших бінарних файлів у git.

Вся "не зберігати бінарні файли у контролі джерела" викладена з конкретної причини: Якщо у вас є вихідний код, який компілюється, не зберігайте фактичну компіляцію, а лише вихідний код. Зображення та візуальні активи не мають "джерела", тому їх слід відслідковувати в контролі версій.

Я вважаю, що рекомендованим способом з Git є використання підмодуля (введеного в Git 1.5.3), який в основному є окремим сховищем, пов'язаним з основним. Ви зберігаєте свої зображення (та інші двійкові активи) у підмодулі. Потім це можна перевірити в головному сховищі або вліво, залежно від необхідного.

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

"Підтримка підмодуля Git дозволяє сховищу містити, як підкаталог, замовлення зовнішнього проекту. Підмодулі підтримують власну ідентичність; підтримка підмодуля просто зберігає місцезнаходження сховища підмодуля та виконує ідентифікатор, тому інші розробники, які клонують проект, що містить (" superproject ") може легко клонувати всі підмодулі при одній редакції. Можливі часткові перевірки суперпроекту: ви можете сказати Git клонувати жоден, деякі або всі підмодулі."

Також розмір не повинен бути суттєвою проблемою, якщо зображення не змінюються часто. Ви також можете запускати команди для обрізання / зменшення розміру, наприклад:

git gc
git gc-aggressive
git prune

Так .

Скажімо, ви випускаєте програмне забезпечення версії 1.0. Для версії 2.0 ви вирішили повторити всі зображення, щоб бути з тінями. Отже, ви робите це і випускаєте 2.0. Тоді хтось клієнт, який використовує 1.0 і не може оновити до 2.0, вирішує, що хоче програму іншою мовою. Вони дають вам $ 1G, щоб це зробити, тож ви впевнені. Але в іншій культурі деякі ваші фотографії не мають сенсу, тому вам доведеться їх змінювати ...

Якщо ви б утримували свої зображення в контролі джерел, це легко, на основі 1,0 ви вносите зміни в зображення (серед іншого), будуєте, випускаєте. Якби у вас цього не було у керуванні джерелами, у вас було б набагато складніше, оскільки вам доведеться знаходити старі зображення, змінювати їх, а потім будувати.

Якщо він є частиною Проекту, він повинен бути в ДКС . Як досягти цього найкращого, може залежати від VCS або від того, як ви організовуєте проект. Може бути, репо для дизайнерів, і лише результати в репортаторі кодера, або лише "Джерела зображень" (я колись мав проект із лише .svg файлом та зображеннями, генерованими за допомогою кліпу make / inscape).

Але якщо VCS не в змозі це впоратися або стане непридатним, я б сказав, що це не правильний інструмент для вашої роботи.

Поки у мене не було проблем із розміщенням «звичайних» обсягів графіки (макети, концепції та графіки сторінок) для веб-проектів у git.

Якщо ви зберігаєте свої зображення в SCM: так. Без сумнівів.

Якщо ви зберігаєте свої зображення в git: це стає більш складним.

git дуже хороший з текстовими файлами, але за своєю суттю не надто гарячий із бінарними файлами. У вас виникнуть проблеми з розміром переданих даних, коли ви клонуєте або натискаєте, ваші .git каталоги будуть рости, і ви можете отримати правильний безлад зі злиттям (тобто, як ви злите 2 зображення!)

Одна з відповідей - використовувати підмодулі, оскільки це означає, що зв’язок між вашим проектом та зображеннями буде слабкішим - тому вам не доведеться керувати зображеннями, як ніби вони були частиною вашого джерела, але все одно тримайте їх під контролем та не маючи хвилює їх розгалуження - якщо припустити, що підпроект є лише «плоским» сховищем даних, яке не переживає ту саму дію під час звичайного процесу розробки.

Інша відповідь - вкласти їх у інший проект, ніколи не розгалужувати його та забезпечити, щоб кожен, хто взяв на себе цей проект, негайно підштовхнув його вгору за течією - ніколи не дозволяйте двом людям змінювати одну і ту ж версію файлу - вам це стане найскладнішим аспект як git не призначений для такого нерозподіленого робочого процесу. Для виконання цього правила вам доведеться використовувати старомодні методи спілкування.

Третя відповідь - це розмістити їх в іншому SCM цілком, що краще орієнтуватись на роботу із зображеннями.

Додаючи до відповіді @ haylem, зауважте, що розмір відіграє великий фактор у цьому. Залежно від VCS, він може не працювати з тонами зображень. Коли клони або великі поштовхи починають знімати всю ніч, то це справді занадто пізно, оскільки всі зображення вже є у вашому сховищі.

Плануйте великі картини та майбутнє зростання. Ви не хочете, щоб два роки брати участь у цьому проекті та мати "о, лайно, можливо, РЕПО трохи завелике ".

Я безумовно погоджуюся, що зберігати їх технічно та економічно можливо. Я б поставив запитання: "чи є ці зображення частиною товарного товару або частиною вмісту товару?" Не те, що ви не можете зберігати вміст у GIT (або будь-якому іншому VCS), але це окрема проблема для окремого VCS.