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