"Depende." Para el seguimiento normal del desarrollo, no. Sin embargo, para implementaciones en la nube y DevOps, a menudo es conveniente o incluso necesario.
La mayoría de las veces,
@ptyx es correcto . De hecho, su "no" podría expresarse de manera algo más enfática. Algo así como "No. ¡No! ¡ OMG NO! "
¿Por qué no almacenar activos minificados o comprimidos en un sistema de control de código fuente como Git?
Pueden ser regenerados casi trivialmente por su proceso de compilación sobre la marcha desde el código fuente. Almacenar activos comprimidos es básicamente almacenar el mismo contenido lógico dos veces. Viola el principio de "no te repitas" (también conocido como DRY ).
Una razón menos filosófica pero más práctica es que los activos minificados / optimizados tienen una compresibilidad muy pobre cuando se almacenan en Git. Los sistemas de control de código fuente reconocen los cambios ("deltas") entre diferentes versiones de cada archivo almacenado. Para hacer eso, "difunden" el último archivo con la versión anterior, y usan estos deltas para evitar almacenar una copia completa de cada versión del archivo. Pero las transformaciones realizadas en el paso de minificar / optimizar a menudo eliminan las similitudes y puntos de referencia que utilizan los algoritmos diff / delta . El ejemplo más trivial es eliminar saltos de línea y otros espacios en blanco; El activo resultante es a menudo solo una larga línea. Muchas partes del proceso de compilación web: herramientas como Babel , UglifyJS , Browserify ,Less y Sass / SCSS : transforman activos de forma agresiva. Su producción es perturbable; pequeños cambios de entrada pueden conducir a cambios importantes en la salida. Como resultado, el algoritmo diff a menudo creerá que ve un archivo casi completamente diferente cada vez. Sus repositorios crecerán más rápidamente como resultado. Sus discos pueden ser lo suficientemente grandes y sus redes lo suficientemente rápidas como para no ser una gran preocupación, especialmente si existiera un valor para almacenar los activos minimizados / optimizados dos veces, aunque según el punto 1, las copias adicionales pueden ser solo 100% inútiles inflar.
Sin embargo, hay una gran excepción a esto: DevOps / implementaciones en la nube. Varios proveedores de nube y equipos de DevOps usan Git y similares no solo para rastrear actualizaciones de desarrollo, sino también para implementar activamente sus aplicaciones y activos en servidores de prueba y producción. En este rol, la capacidad de Git para determinar eficientemente "¿qué archivos cambiaron?" es tan importante como su capacidad más granular para determinar "¿qué cambió dentro de cada archivo?" Si Git tiene que hacer una copia de archivo casi completa para los activos minimizados / optimizados, eso lleva un poco más de tiempo de lo contrario, pero no es gran cosa ya que todavía está haciendo un excelente trabajo ayudando a evitar una copia de "cada archivo en el proyecto" en cada desplegar ciclo.
Si está utilizando Git como motor de implementación, el almacenamiento de activos minimizados / optimizados en Git puede cambiar de "¡no!" a deseable. De hecho, puede ser necesario, por ejemplo, si carece de oportunidades sólidas de compilación / posprocesamiento en los servidores / servicios en los que implementa. (La forma de segmentar los activos de desarrollo e implementación en ese caso es una lata separada de gusanos. Por ahora, es suficiente saber que se puede administrar de varias maneras, incluso con un único repositorio unificado, múltiples sucursales, subrepositorios o incluso múltiples repositorios superpuestos. )
/dev/null.