Control de versiones de un sitio web: archivos front-end de desarrollo / producción

Estoy tratando de pensar en una mejor manera de controlar la versión de los proyectos de nuestro sitio web. Tenga en cuenta que solo soy un desarrollador front-end, así que no tengo un conocimiento profundo de VCS.

Los flujos de trabajo están cambiando y los hábitos de control de versiones anteriores se vuelven obsoletos. El principal problema es que hay 2 matrices de archivos front-end para cada sitio web.

El entorno de desarrollo (menos archivos, js sin comprimir, imágenes, etc.). El entorno de construcción, "engullido" (todo comprimido y no legible por los humanos).

Pero no puede vender un sitio web con sus archivos fuente. Bueno, no se siente del todo bien.

Existe la solución de tener 2 repositorios: una compilación, un desarrollador, con Gulp enviando archivos dev al directorio de compilación. Pero es una molestia de mantener, con las pequeñas empresas no creo que sea tan bueno. Crea muchos repositorios, y la gente tiene que manejar con varios repositorios, a veces incluso con un repositorio svn, surgen problemas.

Entonces también existe la solución de tener 1 repositorio: los archivos fuente y los archivos prod en el mismo svn. Pero luego es necesario eliminar los archivos de origen cuando el sitio web pasa del servidor de desarrollo local al servidor de producción (por lo que hay diferentes archivos en un único repositorio, según su ubicación, desarrollo o producción ...). Por lo que escuché, no es bueno

¿Cuál es la forma correcta de administrar un flujo de trabajo front-end de Gulp con respecto al sistema de control de versiones?

Una regla básica del control de código fuente es que solo necesita colocar artefactos escritos manualmente en el repositorio (los archivos fuente originales), todo lo que se puede "compilar" o "generar" no necesita almacenarse allí, ya que producirá redundancia . Uno puede (opcionalmente) almacenar salidas / partes intermedias de un proceso de compilación en un repositorio (a veces también llamado artefactos), cuando los pasos para reproducirlos no son completamente automáticos, o para propósitos de almacenamiento en caché, cuando los pasos de compilación para reproducir la salida son lentos .

Entonces, si tiene un proceso completamente automatizado para generar los archivos de producción a partir de sus archivos fuente de desarrollo, solo necesita poner los archivos de desarrollo en control de origen (junto con los scripts para crear los archivos de producción). Si no, establezca dicho proceso. Asegúrese de que nadie tenga que manipular los archivos de producción manualmente después de que se hayan generado desde la fuente. Si desea implementar "directamente" desde su VCS, asegúrese de tener un script de implementación que extraiga los archivos fuente del desarrollador del control de origen, realice la "gulpificación" y transfiera los archivos resultantes a la producción en un solo paso.

Por supuesto, si desea utilizar el control de origen también como una "copia de seguridad del hombre pobre" o como un caché para sus archivos de producción, puede configurar un segundo repositorio para este propósito y colocar una copia de la estructura del archivo de producción después de la generación. Este repositorio no servirá para el desarrollo y, una vez configurado, no debería tener que mantenerlo manualmente. Por lo tanto, asegúrese de que no haya pasos manuales para realizar copias de seguridad en este "repositorio de productos" . Incluya los pasos necesarios en el script de implementación que realiza la copia de seguridad automáticamente. Piense en agregar un script de copia de seguridad por separado si no puede prohibir los cambios manuales en la producción después de la implementación. De esa manera, puede mantener el proceso mantenible incluso si tiene recursos limitados.

Y sí, este debería ser un segundo repositorio estrictamente separado, porque tiene un propósito completamente diferente y un ciclo de vida diferente al del repositorio de desarrollo. Lo usa solo para copias de seguridad, no para el control de origen, que es un proceso diferente.