When building a website (for the sake of clarity an HTML/JS only website) I use gulp to compile and concat some files which are then placed in a build/ folder.
The folder structure looks something like this:
├── 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
If I include all these files in a git repo, all of my changes will be committed twice. That is: a change in assets/stylesheets/style.scss will also lead to a change in build/styles.min.css. However, if I decide to exclude the build/ folder from the repository, you will need certain development tools on the production server (i.e. gulp, npm, etc.) This can sometimes be difficult when there's limited privileges on the production server. Obviously excluding the assets/ folder is not an option as you will lose the source for your compiled files.
Therefore my question is: what is considered best practice to deploy this on a production server? Do you include the build/ folder in the repo, do you compile the build/ folder on the production server or is there a third solution?
Although not everybody might agree on what the best solution is for this problem, I think there is a third solution you have missed and that I would generally prefer. You can build all the files on your development machine, and then deploy the files that were built to your production server. That would usually only be a copy action.
This way you will not need to have any development tools on your server and you will not have build output in your version control system.
来源：https://stackoverflow.com/questions/32097479/how-to-deploy-gulp-on-production-server