Cómo implementar Gulp en el server de producción

Al build un website (en aras de la claridad, un website HTML / JS solamente) utilizo gulp para comstackr y concatenar algunos files que luego se colocan en una build/ carpeta.

La estructura de la carpeta se ve más o less así:

 ├── assets │  ├── images │  ├── javascripts │  │  └── app.js │  └── stylesheets │  └── style.scss ├── bower.json ├── build │  ├── bower_components │  ├── images │  ├── index.html │  ├── scripts.min.js │  └── styles.min.css ├── gulpfile.js ├── index.html ├── node_modules │  ├── gulp-module-1 │  └── gulp-module-2 ├── package.json └── README 

Si incluyo todos estos files en un repository git, todos mis cambios se confirmarán dos veces. Es decir: un cambio en assets/stylesheets/style.scss también dará lugar a un cambio en build/styles.min.css . Sin embargo, si decido excluir la build/ carpeta del repository, necesitará ciertas herramientas de desarrollo en el server de producción (es decir, gulp, npm, etc.). Esto a veces puede ser difícil cuando hay privilegios limitados en el server de producción. Obviamente, excluir la carpeta assets/ no es una opción, ya que perderá la fuente de sus files comstackdos.

Por lo tanto, mi pregunta es: ¿qué se considera la mejor práctica para implementar esto en un server de producción? ¿Incluye la build/ carpeta en el repository, comstack la build/ carpeta en el server de producción o hay una tercera solución?

Aunque no todos pueden estar de acuerdo en cuál es la mejor solución para este problema, creo que hay una tercera solución que se ha perdido y que generalmente preferiría. Puede comstackr todos los files en su máquina de desarrollo y luego implementar los files que se crearon en su server de producción. Eso normalmente solo sería una acción de copy.

De esta forma, no necesitará tener ninguna herramienta de desarrollo en su server y no tendrá salida de compilation en su sistema de control de versiones.