Должен ли минимизированный CSS храниться в Git?

Я использую Gulp для создания минимизированного CSS из моего кода SASS для проекта, над которым я работаю.

Я задавался вопросом, считается ли это наилучшей практикой для восстановления этого уменьшенного CSS при запуске из Git вживую ...

или

Хранить минимизированные CSS-файлы в Git, чтобы они автоматически запускались в производство без дальнейшей работы со стороны сервера?

Я был бы признателен за идеи людей по этому поводу. Спасибо!

version-control git css deployment Коннор Герни
источник

Есть только одно место, уменьшенное css / js / etc. должны быть сохранены: /dev/null.

R .. GitHub ОСТАНОВИТЬ ЛЬДА

(Это потому, что ваш веб-сервер вполне способен использовать gzip-транспорт.)

R .. GitHub ОСТАНОВИТЬ ПОМОЩЬ ICE

Хранение сжатого и несжатого CSS означает, что теперь у вас есть две версии одного и того же. Какая каноническая версия? Легко представить сценарий, когда один разработчик обновляет сжатый CSS, а другой обновляет несжатый CSS. Ваши два актива теперь разошлись. Конечно, процесс должен помешать этому, но это реалистичная перспектива, например, с новым разработчиком в команде.

Qwerky

Ответы:

"Это зависит." Для нормального отслеживания разработки нет. Однако для облачных и DevOps развертываний это часто удобно или даже необходимо.

В большинстве случаев @ptyx верен . В самом деле, его «нет» можно сформулировать несколько более решительно. Что-то вроде "Нет. Нет! Боже, нет! "

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

Они могут быть почти тривиально восстановлены вашим процессом сборки на лету из исходного кода. Хранение сжатых активов - это в основном хранение одного и того же логического контента дважды. Это нарушает принцип «не повторяйся» (он же СУХОЙ ).
Менее философская, но более практичная причина заключается в том, что минимизированные / оптимизированные активы имеют очень плохую сжимаемость при хранении в Git. Системы контроля версий работают, распознавая изменения («дельты») между различными версиями каждого сохраненного файла. Чтобы сделать это, они «различают» последний файл с предыдущей версией и используют эти дельты, чтобы избежать сохранения полной копии каждой версии файла. Но преобразования, сделанные на этапе минимизации / оптимизации, часто удаляют сходства и путевые точки, используемые алгоритмами diff / delta . Самый тривиальный пример - удаление разрывов строк и других пробелов; результирующий актив часто составляет всего одну длинную линию. Многие части процесса веб-сборки - такие инструменты, как Babel , UglifyJS , Browserify ,Меньше , а Sass / SCSS - агрессивно трансформируют активы. Их продукция возмущена; небольшие изменения на входе могут привести к значительным изменениям на выходе. В результате алгоритм diff часто полагает, что каждый раз он видит почти совершенно другой файл. В результате ваши репозитории будут расти быстрее. Ваши диски могут быть достаточно большими, а ваши сети - достаточно быстрыми, что не представляет большой проблемы, особенно если есть смысл хранить минимизированные / оптимизированные ресурсы дважды - хотя, исходя из пункта 1, дополнительные копии могут быть просто на 100% бессмысленными. навороты.

Однако есть серьезное исключение: DevOps / облачные развертывания. Ряд поставщиков облачных услуг и групп разработчиков DevOps используют Git и аналогичные системы не только для отслеживания обновлений разработки, но и для активного развертывания своих приложений и ресурсов на тестовых и производственных серверах. В этой роли способность Git эффективно определять, «какие файлы изменились?» так же важна, как и его более детальная способность определять "что изменилось в каждом файле?" Если Git должен сделать почти полную копию файла для минимизированных / оптимизированных ресурсов, это займет немного больше времени, чем в противном случае, но это не проблема, так как он по-прежнему отлично работает, помогая избежать копирования «каждого файла в проекте» на каждом развернуть цикл.

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

Джонатан Юнис
источник

Спасибо тебе за это! Очень признателен. Вместо этого я пометил это как ответ, так как это кажется намного лучше объясненным.

Коннор Герни

Git не хранит только дельты. SVN делает, но Git использует гораздо более сложный механизм для хранения файлов. Некоторые люди говорят вам, что он хранит полную копию каждого файла, но, насколько я понимаю, это также неверно. Я не буду пытаться разобраться в том, что он делает, так как сам не до конца понимаю.

jpmc26

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

jpmc26

Могут ли DevOps просто использовать ловушки git для автоматического запуска минимизации на развернутом сервере, получая лучшее из обоих миров?

Баттл Буткус

@ButtleButkus Зависит от развернутого сервера. Чтобы зависеть от почтовых хуков, вы должны либо 1 / предположить, что на цели присутствуют соответствующие транспортеры, минификаторы и оптимизаторы, либо 2 / загрузить их до запуска почтовых хуков. 1 / рискованно. 2 / накладывает затраты на загрузку / задержку при каждом развертывании. В нем также представлены новые возможные режимы сбоев и требование отладки пост-хуков в удаленной, непрозрачной, переходной среде. Не идеально. Так что крючки - это не серебряная пуля. Предварительное преобразование / оптимизация активов могут быть не элегантными, но они надежны и прагматичны.

Джонатан Юнис

Нет.

Контроль источника должен содержать только источник. Если он сгенерирован из исходного кода, он там не принадлежит - и должен генерироваться вашим процессом сборки.

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

ptyx
источник

Думайте о сгенерированном коде так же, как о исполняемом коде.

candied_orange

Этот принцип не всегда верен. Если у вас есть файлы, созданные с помощью тяжеловесных инструментов, которые пользователь не ожидает, может иметь смысл поместить сгенерированные файлы в git. По configureэтой причине многие даже помещают сгенерированные сценарии autoconf в git.

R .. GitHub ОСТАНОВИТЬ ЛЬДА

@R ..: В идеале у вас есть отдельный репозиторий артефактов для этих вещей, но реальность редко бывает идеальной.

Кевин

@R вы можете пойти на компромисс - но это только так. И в случае минимизации CSS, я не думаю, что инструменты квалифицируются как «тяжеловесные», «медленные» или «неудобные». Кроме того, существуют альтернативные механизмы внедрения зависимостей (maven, ivy ...), которые хорошо работают и не требуют, чтобы вы помещали сгенерированный код в систему контроля версий.

ptyx,

@ButtleButkus Я не очень разбираюсь в деле Девопса. Я видел, что git используется как (очень удобный и гибкий) механизм транспорта / выпуска / развертывания, а не просто как источник контроля. Если git 'source' и git 'delivery' не разделены (отдельные репозитории или отдельные ветки), это означает, что вам придется несколько скомпрометировать цепочку source-> build-> deliveryable - например, в результате вы получите исходный код и дополнительные ветви, лежащие вокруг, и разработка с неиспользованными бинарными продуктами. Это прагматичный компромисс, но я предпочитаю разделять проблемы, когда могу.

ptyx,