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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Хранение файлов изображений в SubVersion / Git
• Git против SVN с нетекстовыми файлами
• Управление большими двоичными файлами с помощью Git и Git-submodule

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

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

• git-annex - это было давно, но, честно говоря, это мешает.
• Git-Media - Нет личного опыта с этим. Кажется довольно сложным.
• git-fit - попытка создать более простой плагин. Требуется хранилище S3. Хотя я ценю простоту, моя главная проблема с плагином заключается в том, что он довольно неизвестен и поддерживается одним человеком (полное раскрытие информации, я единственный другой коммиттер в это время, и это было для тривиальной проблемы).
• 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 . Как добиться этого лучше всего, может зависеть от VCS или от того, как вы организовали проект. Может быть, репозиторий для дизайнеров, и только результаты репо кодера, или только «Источники изображений» (у меня когда-то был проект только с файлом .svg, и изображения были сгенерированы с помощью make / inscape cli).

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

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

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

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

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

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

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

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

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

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

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