Должны ли изображения храниться в репозитории git?

202

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

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

Это считается лучшей практикой? Какие есть другие альтернативы совместному использованию бинарных файлов в проектах, к которым легко может получить доступ распределенная группа?

Spong
источник
17
Когда вы говорите «картинки», мы говорим о 26-мегабайтных DSLR-файлах, 1-мегабайтных игровых текстурах или <100k png иконок? (Я собирался ответить «это зависит», но я воздержусь)
Брук
2
@Brook: я как бы предполагал, что мы говорим о значках или небольших графических элементах для веб-сайтов. Текстуры игр, необработанные файлы графического дизайна или точная графика для редактирования документации могут быть другой историей, вы правы.
Хайлем
6
Я лично думал, что он имел в виду образы ISO, а не картинки.
Махмуд Хоссам
2
Это должно быть действительно для небольших / средних размеров веб-изображений. Вызывает беспокойство то, что некоторые разработчики подписей начнут вставлять туда каждое большое оригинальное изображение, когда я думаю, что, вероятно, следует использовать что-то еще.
Спонг
6
Читаете этот вопрос сегодня? Посмотрите на ответ ниже на git lfs. Это, вероятно, то, что вы хотите. programmers.stackexchange.com/a/306882/92506
Джоннибот

Ответы:

188

Ваши изображения являются оригинальными работами или их можно восстановить (гарантировано?) Из другого места? Нужны ли они для доставки программного обеспечения, созданного из исходного кода? Если они оригинальны, они нуждаются в резервном копировании. Поместите их в свой контроль версий, если они никогда не изменятся, штраф за место такой же, как и у резервной копии, и они находятся там, где они вам нужны.

Могут ли они быть отредактированы, чтобы изменить внешний вид программного обеспечения, случайно или намеренно? Да - тогда они ДОЛЖНЫ как-то контролироваться ревизиями, зачем использовать другой способ, когда у вас уже есть идеальное решение. Зачем вводить «копировать и переименовывать» контроль версий из темных веков?

Я видел, как оригинальная работа всего проекта становилась «пуфом», когда умер жесткий диск MacBook графического дизайнера, и все потому, что кто-то, с бесконечной мудростью, решил, что «двоичные файлы не принадлежат к управлению оборотами», и графические дизайнеры (по крайней мере, этот ) не склонны быть хорошими с резервными копиями.

То же относится и к любым двоичным файлам, которые соответствуют вышеуказанным критериям.

Единственная причина, по которой это не так, - дисковое пространство. Я боюсь, что за $ 100 / терабайт, это оправдание носить немного тонким.

mattnz
источник
44
Кстати: Интернет не является надежным источником. Если вы загрузили изображение с «bobsfreestuff.com», его, вероятно, не будет на следующей неделе.
Mattnz
16
+1 - и должно быть + больше. Смысл контроля версий заключается в том, чтобы позволить вам восстановить / откатиться к чему угодно, каким бы оно ни было, В НЕКОТОРОЕ ВРЕМЯ. Единственный способ быть на 100% в том, что вы можете вернуть то, что должно было быть на тот момент, это поставить ВСЁ под контроль версий. Это источник, изображения, ресурсы, полезные / поддерживающие PDF-файлы. Черт возьми, я даже вставил образы Zipped CD. Мне даже было известно, что виртуальная машина ВМ (включая VMDK) включена в систему контроля версий. Кажется экстремальным? Спас бекон 2 года спустя.
quick_now
3
На 100% согласен. Если изображения являются частью программного обеспечения, они должны контролироваться редакцией.
Дин Хардинг
14
Единственная причина, по которой я бы не согласился, заключалась в том, что это сделало ваш репозиторий громоздким для клонирования до такой степени, что разработчики должны были подумать «действительно ли я хочу потратить время на клонирование этого, или я могу просто сделать X в другой ветке». Если это произойдет, убедитесь, что все очень быстро перестроено
Brook
5
+1 за пункт о необходимости его для развертывания. Если я клонирую ваш репозиторий, потому что я новый член команды или что-то в этом роде, то он должен работать из коробки . Это включает наличие достаточно умного эквивалента make-файла, чтобы при необходимости получить необходимые сторонние библиотеки.
Спенсер Рэтбун
66

Почему, черт возьми, нет? :)

Да, хранение двоичных файлов считается плохой практикой, но я никогда особо не беспокоился об изображениях.

В худшем случае, если у вас есть тонны, храните их где-нибудь еще или используйте внешние или расширение для двоичной поддержки. И если изображения не будут меняться так часто, то в чем проблема? Вы не получите большую жирную дельту. И если они удаляются со временем, только ваш сервер немного страдает от хранения истории, но клиенты ничего не увидят.

На мой взгляд, вам не стоит об этом беспокоиться - при условии, что вы не храните ГБ из них.

Однако вы можете хранить только «исходные» изображения: SVG, макросы LaTeX и т. Д. И иметь окончательные изображения, сгенерированные вашей системой сборки. Это, вероятно, даже лучше, если вы можете. Если нет, то не беспокойтесь.

(С учетом всего вышесказанного, Git великолепен для текстовых файлов, но не является лучшим VCS для изображений. Дайте нам больше контекста и метрик, если можете)


Для получения дополнительной информации вы можете посмотреть эти вопросы и ответы:

haylem
источник
4
+1 за хранение исходного кода, но если они могут провести тестирование разработки без полной сборки, то это может испортить его. Это также означает, что вам нужно будет собрать все изображения перед началом работы утром
TheLQ
@TheLQ: Полагаю, но тогда, может быть, у вас должны быть каскадные сборки, в которых ваши нижестоящие (тестовые) сборки могут полагаться только на восходящие (фактическая сборка). А затем экспортируйте их в общую папку для повторного использования тестерами локально. Очевидно, это подразумевает некоторую инфраструктуру, но это был бы мой способ ведения дел в относительно значительной команде.
Хайлем
Что такое бинарные файлы?
Даниэль Пендергаст
1
@DantheMan: en.wikipedia.org/wiki/Binary_file
Хейлем,
5
"Почему, черт возьми, нет?" - потому что, если ваш репо превышает 2 ГБ, Bitbucket (и я только что попробовал это с Github) отклонит ваш репо. Так что будьте готовы разместить свои собственные репо, если вы переполните их тоннами изображений.
Джез
48

Этот вопрос довольно старый, но это распространенный вопрос, который возникает при работе с Git, и есть некоторые успехи в современных решениях для хранения больших файлов в репозитории Git с момента последнего ответа.

Для хранения больших файлов в Git существуют следующие проекты:

  • git-annex - это было давно, но, честно говоря, это мешает.
  • Git-Media - Нет личного опыта с этим. Кажется довольно сложным.
  • git-fit - попытка создать более простой плагин. Требуется хранилище S3. Хотя я ценю простоту, моя главная проблема с плагином заключается в том, что он довольно неизвестен и поддерживается одним человеком (полное раскрытие информации, я единственный другой коммиттер в это время, и это было для тривиальной проблемы).
  • git-lfs - Хотя я не использовал это широко, похоже, это Святой Грааль. Он поддерживается Github и доступен во всех их репозиториях по состоянию на октябрь 2015 года, что создает сложность управления файлами на сайте, где хранятся ваши репозитории. Единственным недостатком является то, что это довольно новое, поэтому помимо Github не так много поддержки, хотя Gitlab также имеет поддержку , как и Gitea , и Bitbucket ссылается на поддержку в будущем .

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

Джеймс МакМэхон
источник
9
Впервые за долгое время я так рад, что прокрутил страницу вниз, чтобы прочитать ответы с меньшим количеством голосов. git lfs - это именно то, что я хочу, и Atlassian даже добавил поддержку для BitBucket Server ! Если бы я мог поднять это миллион раз, я бы сделал это.
Джоннибот
7
@jonnybot, спасибо. Я запоздалый ответ, так что я не получил большой видимости, но после того, как я сам использовал git-lfs, я думаю, что это лучшее текущее решение для хранения бинарных файлов в git.
Джеймс МакМэхон
45

Целостное «не хранить двоичные файлы в контроле исходного кода» изложено по определенной причине: если у вас есть исходный код, который компилируется, храните не фактическую компиляцию, а только исходный код. Изображения и визуальные ресурсы не имеют «источника», поэтому их следует отслеживать в системе контроля версий.

Джейсон Т Ферингем
источник
4
Иногда визуальные ресурсы имеют «что-то вроде источника», и тогда хорошей идеей будет автоматизировать процесс создания конечного результата и сохранять источник только в системе управления версиями. Примеры: версии растровой графики, сделанные из файлов SVG, ресурсы сайта, вырезанные из листа спрайта.
Танус
Правильно, это совершенно справедливый аргумент.
Джейсон Ферингем
21

Я считаю, что рекомендуемый способ использования Git - использовать субмодуль (представленный в Git 1.5.3), который в основном является отдельным репозиторием, связанным с основным. Вы храните свои изображения (и другие двоичные активы) в подмодуле. Это может быть затем извлечено из основного хранилища или оставлено, в зависимости от того, что требуется.

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

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

Кроме того, размер не должен быть серьезной проблемой, если изображения меняются не часто. Вы также можете запустить команды для сокращения / уменьшения размера, такие как:

git gc
git gc-aggressive
git prune
Дэн Диплом
источник
7

Да .

Допустим, вы выпускаете версию программного обеспечения 1.0. Для версии 2.0 вы решили переделать все снимки с тенями. Итак, вы делаете это и выпускаете 2.0. Тогда какой-то клиент, который использует 1.0 и не может перейти на 2.0, решает, что ему нужна программа на другом языке. Они дают вам 1G за это, так что говорите наверняка. Но в другой культуре некоторые ваши картины не имеют смысла, поэтому вы должны изменить их ...

Если вы хотите, чтобы ваши изображения находились под контролем исходного кода, это легко: на основе 1.0 вы вносите изменения в изображения (среди прочего), собираете, выпускаете. Если бы вы не имели их в управлении исходным кодом, вам было бы намного сложнее, так как вам пришлось бы искать старые изображения, изменять их, а затем строить.

earlNameless
источник
7

Если он является частью проекта, он должен быть в VCS . Как добиться этого лучше всего, может зависеть от VCS или от того, как вы организовали проект. Может быть, репозиторий для дизайнеров, и только результаты репо кодера, или только «Источники изображений» (у меня когда-то был проект только с файлом .svg, и изображения были сгенерированы с помощью make / inscape cli).

Но если VCS не может справиться с этим или становится непригодным для использования, я бы сказал, что это не самый подходящий инструмент для вашей работы.

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

keppla
источник
5

Если вы храните ваши изображения в SCM: да. Без сомнения.

Если вы храните ваши изображения в git: это становится сложнее.

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

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

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

Третий ответ - полностью поместить их в другой SCM, который лучше приспособлен для работы с изображениями.

gbjbaanb
источник
0

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

Планируйте большие картинки и будущий рост. Вы не хотите два года участвовать в этом проекте и иметь «о, чёрт, может быть, репо слишком велико».

TheLQ
источник
1
Ваш ответ несколько не имеет значения, так как вопрос специфичен для git. Вы случайно не знаете, играет ли размер большой (или какой-либо) фактор для репозиториев git?
Яннис
@Yannis Должно быть, я пропустил это первое предложение ... AFAIK, git лучше с большими репозиториями, но проблема с размером по-прежнему актуальна, так как огромные клоны или толчки
TheLQ
С GIT тривиально легко переставить репозитории и создать частичные клоны и т. Д., Если это станет проблемой. Не путайте историческую патоку инструментов контроля версий десятилетий назад с сегодняшней.
Mattnz
0

Я определенно согласен с тем, что технически и экономично их хранение возможно. Вопрос, который я хотел бы задать, это "являются ли эти изображения частью продукта доставки или частью содержимого продукта доставки?" Не то, чтобы вы не могли хранить контент в GIT (или любой другой VCS), но это отдельная проблема для отдельной VCS.

Уайетт Барнетт
источник