Чи слід зберігати в Git мінімізований CSS?

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

Мені було цікаво, чи вважається найкращою практикою відновлення цього мінімізованого CSS при натисканні наживо з Git ...

або

Щоб зберігати мінімізовані файли CSS у Git, щоб вони автоматично виводились на виробництво без подальшої роботи з боку сервера?

Я би вдячний ідеям людей з цього приводу. Дякую!

— Коннор Герні
джерело

Існує лише одне місце, що мінімізоване css / js / тощо. повинні бути збережені: /dev/null.

— R .. GitHub ЗАСТАНОВИТЬ ДІЙЛИ

(Це тому, що ваш веб-сервер цілком здатний використовувати gzipped транспорт.)

— R .. GitHub ЗАСТАНОВИТЬ ДОПОМОГУ ICE

Зберігання як стисненого, так і нестисненого CSS означає, що тепер у вас є дві версії одного і того ж. Яка канонічна версія? Легко уявити сценарій, коли один розробник оновлює стислий CSS, а інший оновлює нестиснений CSS. Зараз ваші два активи розійшлися. Звичайно, процес повинен запобігти цьому, але його реалістична перспектива, наприклад, новий розробник у команді.

— Qwerky

Відповіді:

"Це залежить." Для нормального відстеження розвитку немає. Однак для хмарних та DevOps розгортань це часто зручно або навіть потрібно.

В більшості випадків @ptyx є правильним . Дійсно, його «ні» можна було б сказати дещо виразніше. Щось на кшталт "Ні. Ні! OMG НІ! "

Чому б не зберігати мінімізовані або стислі активи в системі управління джерелами, як 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, щоб автоматично запускати мінімізацію на розгорнутому сервері, отримуючи найкращі з обох світів?

— Buttle Butkus

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

— Джонатан Юніс

Ні.

Контроль джерела повинен містити лише джерело. Якщо він генерується з джерела, він не належить до нього - і повинен формуватися вашим процесом збирання.

Принципова причина, по якій ви не хочете отримувати артефакти проміжного збору джерел управління, полягає в тому, що якщо ви це зробите, вам стає важко довіритися, чим ви працюєте, походить від джерела, який ви тільки що змінили, або від проміжного продукту, який ви не змогли відновити. .

— ptyx
джерело

Подумайте про згенерований код так, як ви думаєте про виконуваний код.

— candied_orange

Цей принцип не завжди відповідає дійсності. Якщо у вас є файли, згенеровані за допомогою важких інструментів, яких ви не можете очікувати, що користувач може мати їх, можливо, має сенс помістити створені файли в git. З configureцієї причини багато людей навіть кладуть згенеровані сценарії autoconf в git.

— R .. GitHub СТОП ДОПОМОГА ВІД

@R ..: В ідеалі ви підтримуєте окреме сховище артефактів для цих речей, але реальність рідко ідеальна.

— Кевін

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

— ptyx

@ButtleButkus Я не маю багато досвіду щодо справи девепса. Я бачив, як git використовується як (дуже зручний і гнучкий) механізм транспортування / випуску / розгортання, а не як управління джерелом. Якщо «git» і git «доставка» не є окремими (окремі репости або окремі гілки), це означає, що вам доведеться дещо поставити під загрозу ланцюжок джерела-> build->, що постачається - наприклад, ви закінчите виробництво з вихідним кодом і додаткові гілки, що лежать навколо, і розвиток з невикористаними бінарними продуктами. Це прагматичний компроміс, але я вважаю за краще розділяти проблеми, коли можу.

— ptyx