I CSS minificati devono essere memorizzati in Git?

"Dipende". Per il normale monitoraggio dello sviluppo, no. Per le distribuzioni cloud e DevOps, tuttavia, è spesso conveniente o addirittura richiesto.

La maggior parte del tempo, @ptyx è corretto . In effetti, il suo "no" potrebbe essere affermato in modo un po 'più enfatico. Qualcosa come "No. No! OMG NO! "

Perché non immagazzinare risorse minime o compresse nel sistema di controllo del codice sorgente come Git?

1. Possono essere rigenerati quasi banalmente dal tuo processo di compilazione al volo dal codice sorgente. La memorizzazione di asset compressi consiste essenzialmente nel memorizzare lo stesso contenuto logico due volte. Viole il principio "non ripeterti" (alias DRY ).

2. Una ragione meno filosofica ma più pratica è che le risorse miniate / ottimizzate hanno una comprimibilità molto scarsa se conservate in Git. I sistemi di controllo del codice sorgente funzionano riconoscendo le modifiche ("delta") tra diverse versioni di ciascun file memorizzato. Per fare ciò, "diff" l'ultimo file con la versione precedente, e utilizzare questi delta per evitare di memorizzare una copia completa di ogni versione del file. Tuttavia, le trasformazioni apportate nel passaggio Minify / Optimize rimuovono spesso le somiglianze e i waypoint utilizzati dagli algoritmi diff / delta . L'esempio più banale è la rimozione di interruzioni di riga e altri spazi bianchi; l'asset risultante è spesso solo una lunga fila. Molte parti del processo di creazione Web: strumenti come Babel , UglifyJS , Browserify , Meno e < a href="http://sass-lang.com/"> Sass / SCSS - trasforma le risorse in modo aggressivo. La loro produzione è perturbabile; piccoli cambiamenti di input possono portare a grandi cambiamenti nell'output. Di conseguenza, l'algoritmo diff spesso crederà di vedere ogni volta un file completamente diverso. Di conseguenza, i repository cresceranno più rapidamente. I tuoi dischi potrebbero essere abbastanza grandi e le tue reti abbastanza veloci da non costituire un problema, specialmente se ci fosse un valore per memorizzare due volte le risorse miniate / ottimizzate - sebbene sulla base del punto 1, le copie extra potrebbero essere solo al 100% inutili gonfiare.

Tuttavia, c'è una grande eccezione a questo: DevOps / distribuzioni cloud. Un numero di venditori di cloud e team DevOps utilizzano Git e simili non solo per tenere traccia degli aggiornamenti di sviluppo, ma anche per distribuire attivamente le loro applicazioni e risorse ai server di test e di produzione. In questo ruolo, la capacità di Git di determinare in modo efficiente "quali file sono stati modificati?" è tanto importante quanto la sua capacità più granulare di determinare "cosa è cambiato all'interno di ogni file?" Se Git deve fare una copia di file quasi completa per risorse miniate / ottimizzate, ci vuole un po 'più di tempo altrimenti, ma non è un grosso problema dato che sta ancora facendo un lavoro eccellente aiutando ad evitare una copia di "ogni file nel progetto" su ogni ciclo di distribuzione.

Se utilizzi Git come motore di distribuzione, la memorizzazione di risorse miniate / ottimizzate in Git può passare da "no!" desiderabile. In effetti, potrebbe essere necessario, ad esempio se non si dispone di solide opportunità di build / post-elaborazione sui server / servizi a cui si distribuisce. (Come segmentare le risorse di sviluppo e distribuzione in quel caso è una lattina separata di worm.Per ora, è sufficiente sapere che può essere gestito in diversi modi, incluso un singolo repository unificato, più rami, sotto-territori o anche più repository sovrapposti. )

No.

Il controllo del codice sorgente dovrebbe contenere solo l'origine. Se è generato dalla fonte, non appartiene a questo - e dovrebbe essere generato dal tuo processo di compilazione.

La ragione fondamentale per cui non vuoi sottoporre a controllo gli artefatti di build intermedi di controllo è che, se lo fai, diventa davvero difficile credere che ciò che stai usando provenga dalla fonte che hai appena modificato, o da un prodotto intermedio che impossibile ricostruire.