"Dipende." Per il normale monitoraggio dello sviluppo, no. Per le distribuzioni cloud e DevOps, tuttavia, è spesso conveniente o addirittura richiesto.
Il più delle volte,
@ptyx è corretto . In effetti, il suo "no" potrebbe essere dichiarato in modo un po 'più enfatico. Qualcosa del tipo "No. No! OMG NO! "
Perché non archiviare risorse minimizzate o compresse nel sistema di controllo del codice sorgente come Git?
Possono essere quasi banalmente rigenerati dal tuo processo di compilazione al volo dal codice sorgente. L'archiviazione di risorse compresse comporta sostanzialmente la memorizzazione dello stesso contenuto logico due volte. Infrange il principio "non ripetere te stesso" (noto anche come DRY ).
Una ragione meno filosofica ma più pratica è che le risorse minimizzate / ottimizzate hanno una compressibilità molto scarsa se conservate in Git. I sistemi di controllo del codice sorgente funzionano riconoscendo le modifiche ("delta") tra le diverse versioni di ciascun file memorizzato. Per fare ciò, "diff" il file più recente con la versione precedente e usano questi delta per evitare di memorizzare una copia completa di ogni versione del file. Ma le trasformazioni effettuate nella fase di minimizzazione / ottimizzazione spesso rimuovono 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'attività risultante è spesso solo una linea lunga. Molte parti del processo di creazione Web: strumenti come Babel , UglifyJS , Browserify ,Meno e Sass / SCSS : trasformano aggressivamente le risorse. La loro uscita è perturbabile; piccoli cambiamenti nell'input possono portare a grandi cambiamenti nell'output. Di conseguenza, l'algoritmo diff crederà spesso di vedere quasi sempre un file completamente diverso. Di conseguenza, i tuoi repository cresceranno più rapidamente. I tuoi dischi potrebbero essere abbastanza grandi e le tue reti abbastanza veloci da non essere un grosso problema, specialmente se ci fosse un valore per archiviare due volte le risorse minimizzate / ottimizzate, anche se in base al punto 1, le copie extra potrebbero essere inutili al 100% gonfiare.
C'è una grande eccezione a questo, tuttavia: distribuzioni DevOps / cloud. Numerosi fornitori 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 su server di test e produzione. In questo ruolo, la capacità di Git di determinare in modo efficiente "quali file sono cambiati?" è importante quanto la sua capacità più granulare di determinare "cosa è cambiato all'interno di ciascun file?" Se Git deve fare una copia del file quasi completa per risorse minimizzate / ottimizzate, ci vuole un po 'più di quanto farebbe altrimenti, ma non è un grosso problema dato che sta ancora facendo un lavoro eccellente aiutando a evitare una copia di "ogni file nel progetto" su ogni distribuire il ciclo.
Se stai usando Git come motore di distribuzione, la memorizzazione di risorse minimizzate / ottimizzate in Git potrebbe passare da "no!" desiderabile. In effetti, potrebbe essere necessario, ad esempio, se mancano solide opportunità di compilazione / post-elaborazione sui server / servizi su 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 gestita in diversi modi, incluso un singolo repository unificato, più filiali, sottorepository o anche più repository sovrapposti. )
/dev/null.