Должен ли я хранить носители моего сайта в репозитории моего сайта?

Question

У меня есть простое приложение для блога, написанное на Python с использованием Django. Я использую Git для контроля версий этого сайта. Основным содержанием сайта является блог. Записи блога хранятся в базе данных SQLite (которая не контролируется версией, но регулярно резервируется); некоторые записи содержат изображения и другие носители (например, PDF).

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

1. Всякий раз, когда я публикую новую запись в блоге, которая содержит изображение или ссылку на PDF, я должен добавить изображение в репозиторий, а затем скопировать новую версию на рабочий сервер - что кажется большой работой добавить изображение. Было бы проще просто загрузить изображение на сервер (и, конечно, сделать локальную резервную копию).
2. Поскольку этот носитель является контентом , а не code , не представляется необходимым хранить его вместе с самим кодом (и носителями связанного стиля).
3. Репо содержит много бинарных файлов, которые увеличивают общий размер репо; и что более важно,
4. Я никогда не редактировал эти изображения, так зачем держать их под контролем версий?

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

Однако я задался вопросом: существует ли «наилучшая практика» для работы с изображениями контента и другими медиафайлами в репо сайта, в отличие от изображений и т. Д., Которые фактически используются как часть макета и функциональности сайта? 1023 *

---

Редактировать

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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

Это на самом деле не столько ответ, сколько то, что нужно учитывать.

Answer 4

Вы полностью правы по двум пунктам.

1. Вы используете контроль версий для своего кода.
2. Вы создаете резервную копию своей базы данных контента в реальном времени.

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

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

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

Answer 5

Если вы работаете над веб-проектом, я бы порекомендовал создать виртуальный каталог для вашего носителя. Например, мы устанавливаем виртуальный каталог в нашей локальной рабочей копии IIS для / images / / assets / и т. Д., Который указывает на сервер разработки / подготовки, к которому у клиента есть доступ.

Это увеличивает скорость управления исходным кодом (особенно при использовании чего-то неуклюжего, например Visual Source Safe), и если клиент что-то меняет во время тестирования, это автоматически отражается в нашей локальной рабочей копии.

Answer 6

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

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

На мой взгляд, перевод ваших статических файлов в систему контроля версий не приносит никакого вреда. Вы должны поместить их куда-нибудь в репозиторий контроля версий или в обычную файловую систему. поскольку ваши статические файлы никогда не меняются, они не занимают больше места со временем, так в чем же проблема? Я рекомендую вам просто поставить все это под контроль версий и упростить для себя. Лично я регулярно создавал бы резервную копию своей базы данных и передавал ее также в систему контроля версий. Таким образом, у вас есть все в одном месте, и в случае стихийного бедствия вы можете легко сделать новую проверку / экспорт, чтобы восстановить ваш сайт.

Я создал этот веб-сайт. Он имеет более чем PDF-файлы, и все хранится под контролем версий. Если сервер умирает, все, что мне нужно сделать, - это выполнить чистый экспорт и повторно импортировать базу данных и сайт снова и снова.

Answer 7

Системы управления версиями Move не работают хорошо с двоичными файлами, и, как говорится, если они не меняются, это не имеет (небольшой) разницы.

Вам просто нужно решить, что проще: создать резервную копию в репозитории и в многошаговом процессе, чтобы добавить образ / pdf / что угодно, или сохранить для них отдельный набор действий (включая резервное копирование). Лично я бы держал их на контроле версий. Если вы не меняете их, это ничего не вредит. Зачем беспокоиться о чем-то, что не приносит вреда?