Git игнорирует скомпилированный CSS, но сохраняет последнюю версию в состоянии готовности к работе

Question

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

Можем ли мы игнорировать файлы CSS, автоматически скомпилированные моим текстовым редактором из файла LESS?

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

Я всегда компилирую файлы LESS со своего локального компьютера и хочу сохранить его таким образом (поэтому не предлагайте мне использовать Grunt или что-то другое для автоматической компиляции при загрузке страницы пользователем, пожалуйста: P).

Идеальным решением будет сохранить только самый последний файл в репозитории только для файлов CSS. Для истории я бы проверил файлы LESS. Файлы CSS будут доступны только для того, чтобы сайт работал сразу после git clone / pull.

Answer 1

Дайте мне посмотреть, смогу ли я обобщить ваши требования здесь:

• Конечный пользователь должен получать минимизированный CSS при обращении к вашему серверу
• Ваш сервер использует ваше git-репо в качестве источника кода (надеюсь, мастер или производственная ветвь)
• Вам не нужно много минимизированной истории CSS в вашем репо
• Вам нужна читабельная история CSS для разработчика в вашем репо

Это довольно общие требования. Большинство людей используют сценарии развертывания для последовательного выполнения таких действий на каждом производственном этапе - один сценарий, который они могут запустить на сервере для загрузки источника из репозитория, минимизации всех CSS / JS / HTML, обновления менеджера пакетов с учетом любых новых требований. перезагрузите все локальные сервисы, которые нуждаются в перезагрузке, обновлении / разогреве кэшей и т. д. Это может быть простой веб-сервис, который вы пишете, а затем вызываете через ловушку из GitHub / BitBucket /, кто бы ни отправлялся в вашу производственную ветку, или вы можете используйте инфраструктуру развертывания, специально созданную для надежного развертывания.

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

Answer 2

Ключ заключается в том, чтобы различать версионные исходные файлы и итоговые артефакты сборки .

Файлы LESS являются исходными файлами и принадлежат вашему репозиторию Git.,Однако сгенерированные файлы CSS являются продуктом процесса сборки и являются артефактом сборки, так же как файлы Windows .exe / .dll или Java .class.

Артефакты сборки не должны передаваться в источникрепозиторий по нескольким причинам, в том числе:

• добавление шума в историю управления версиями с фиксацией обновления сгенерированных файлов
• вызывает дополнительные конфликты слияния при использовании ветвления / слияния
• не работает, если вы хотите использовать .gitignore для игнорирования файлов;если файл зафиксирован в репозитории, он не будет проигнорирован, и будут отображены изменения

В соответствии с рекомендациями обычно продукты компоновки выделяются в определенный подкаталог корневого каталога проекта, например build,или output, или bin, где хранятся все артефакты сборки.Затем этот единственный подкаталог может быть добавлен в .gitignore.

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

Answer 3

• не фиксируйте файл css в git
• не используйте git push в качестве сценария развертывания
• пишите отдельный сценарий развертывания, который упаковывает ваш код иминимизированный css с вашего локального компьютера и копирует его на ваш производственный сервер

Что касается отправки файлов по сети, если git может это сделать, scp может это сделать.