Использование LESS и контроля версий: должен ли сгенерированный CSS быть включен в репо?

17

Я рассматриваю возможность использования LESS для разработки CSS с обработкой на стороне сервера (или разработки), но я не могу решить, следует ли хранить созданные файлы CSS в контроле версий. Существует множество решений с крючками, но это добавляет программные зависимости к серверу. Крюк можно просто добавить локально, так что места размещения и производства в Интернете будут получать одинаковые файлы. Итак, вопрос:

Должны ли созданные файлы CSS быть включены в контроль версий или нет? Имейте в виду, что для некоторых фреймворков требуется, чтобы файл CSS существовал по определенной причине (например, для тем WordPress требуется файл style.css для распознавания).

Ура!

Изменить: Когда я говорю "учитывая использование LESS", я имею в виду, что это становится требованием. У новых разработчиков не было бы возможности использовать ванильный CSS после выбора в пользу LESS.

Теги:
less
version-control

5 ответов

8
Лучший ответ

Ты очень много ответил на свой вопрос. Это зависит от того, как вы размещаете свой сайт.

Если сервер просто собирается напрямую из репозитория Git:

1) Для создания CSS с LESS необходимо установить программное обеспечение.

2), или вам нужно включить файлы CSS в репозиторий.

Если вы не вытаскиваете прямо из репозитория на своем веб-сервере, у вас может быть сборка script, которая извлекает из git, генерирует CSS и затем передает содержимое на веб-сервер (ы), возможно исключая ненужные файлы из передачи.

По-моему, Git следует использовать, чтобы сохранить весь источник проекта, и ни один из "полученных артефактов" (как упоминалось @thekbb). Разработчики должны иметь все инструменты, установленные для создания полученных артефактов во время разработки и тестирования. Для развертывания на тестовых и производственных серверах сервер автоматической сборки должен взять исходный код и создать только файлы, необходимые для распространения.

В случае разработки программного обеспечения у вас будет файл Makefile с файлами .C и .H(например) в вашем репозитории Git. Разработчики и сервер сборки имеют установленный компилятор, который создаст исполняемую или скомпилированную библиотеку. Когда файлы упакованы для распространения, исходный код не является частью архива.

Для веб-разработки у вас есть исходные файлы, такие как оригинальная графика, HTML-шаблоны и файлы LESS. Разработчики и сервер сборки могут запускать скрипты для генерации ресурсов сайта (CSS из файлов LESS, статических HTML-страниц из шаблонов, сглаженных изображений в нескольких размерах/форматах и ​​т.д.). Когда сервер сборки развертывает новые сборки, он копирует только файлы, необходимые сервером, исключая исходную графику, шаблоны и файлы LESS.

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

  • 1
    Это отличный ответ, но какой выбор, по вашему мнению, является оптимальным, если вы используете фреймворк, требующий CSS-файл, такой как WordPress?
  • 1
    Смотрите мой обновленный ответ о том, что я считаю оптимальным. По сути, то, что говорит @thekbb: не храните производные артефакты в вашем хранилище.
11

Проверка полученных артефактов почти всегда неоптимальна.

Я не голосовал против проверки в .css. Это только вопрос времени, пока один из ваших сверстников или преемников не проверит в редакторе .css, а не .less. Затем, когда вы измените значение .less, предыдущее изменение будет потеряно.

  • 1
    Я бы предложил привести ответ с последней строки. Сделал бы ответ потоком немного лучше.
  • 1
    Вы имеете в виду не регистрироваться в .css?
Показать ещё 1 комментарий
2

Должны ли созданные файлы CSS быть включены в управление версиями или нет?

В теории они не должны, но для практичности я обычно проверяю в сгенерированном файле css. Причина в том, что он упрощает развертывание, поскольку я развертываю с помощью git; Мне не нужно было бы устанавливать меньше компилятора на сервере и, как правило, даже на машине, с которой я развертываюсь (в отличие от машины, на которой я разрабатываю). Это может быть полезно, если у вас есть отдельный разработчик и развертыватель, но иногда также может быть полезен, даже если вы развертываете себя.

Теперь есть недостатки в этом:

  • Вы не можете использовать git add --patch (или вам действительно нужно быть очень осторожно при этом)
  • Вы не должны напрямую изменять .css; вместо этого я обычно использую вторичный файл .css для внесения незначительных изменений без изменения первичного файла .less или .css. Вы также можете скомпилировать бездейственный файл прямо в мини-код css, чтобы сделать его менее заманчивым для изменения созданного css.
  • Разработчики должны настроить свою машину для использования автоматического инструмента перекомпиляции (например, SimpLess или Less.app), поэтому файл .css обновляется, как только они сохраняются в файле .less. Без автоматизации вы столкнетесь с риском того, что css не будет соответствовать файлу с записями меньше.

Я бы не сделал то же самое при компиляции из .C и .H файлов, хотя, поскольку сгенерированный двоичный файл для них специфичен для платформы, а также .less/.css файл, как правило, является очень небольшой частью более крупного веб-проекта, поэтому объем служебных данных дополнительного файла невелик.

0
Хороший вопрос. Если вы можете абсолютно гарантировать, что файл CSS будет обновляться при обновлении LESS, то, возможно, да - в соответствии с комментарием @Scott Simpson. Я подозреваю, что это будет трудно гарантировать, и что произойдет, когда новый разработчик получит копию CSS в тот день, когда они не синхронизированы? Кроме того, конечно, и я изначально не думал об этом, что произойдет, если новый разработчик затем обновит файл CSS, а не LESS? Если CSS должен быть построен и не является частью архива, я вижу меньше проблем.
  • 0
    Вы выдвигаете хорошие моменты, но, вероятно, лучше бы использовать ответ, если перефразировать вопросы о том, что произойдет, в виде списка возможных недостатков.
0

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

  • 4
    Вы можете использовать тот же аргумент для фиксации других артефактов сборки, таких как исполняемые файлы или библиотеки DLL. Теоретически у каждого была бы, по крайней мере, одна и та же цепочка инструментов и сценарий сборки для генерации всех артефактов.
  • 0
    @Scott - LESS будет требованием для проекта, если он используется.
Показать ещё 1 комментарий

Ещё вопросы

Сообщество Overcoder
Наверх
Меню