I’m trying to think of a better way to version control our website projects. Keep in mind I’m only a front-end dev so I don’t have a profound knowledge of VCS.
Workflows are changing, and past version control habits become obsolete.
The main problem is there are 2 arrays of front-end files for each website.
The dev environment (less files, uncompressed js, images, etc). The build environment, “gulpified” (everything compressed and not readable by humans).
But you can’t sell a website with its source files. Well, it feels not quite right.
There’s the solution of having 2 repos : one build, one dev, with gulp sending dev files to build directory. But its a hassle to maintain, with small companies I don’t think it’s that great. It creates a lot of repos, and people have to manage with several repos, sometimes even with one svn repo, problems arise.
So there’s also the solution of having 1 repo : the source files and the prod files in the same svn. But then it is needed to remove the source files when the website goes from local dev server to production server (so there are different files in a single repository, based on its location, dev or production..). From what I heard, it’s not good
What is the correct way of managing a gulp front-end workflow in regard to version control system ?
One basic rule of source control is that you need only to put manual written artifacts into the repo (the original source files), everything which can be “compiled” or “generated” does not need to be stored there, because it will produce redundancy. One can (optionally) store intermediate outputs/parts of a build process in a repo (sometimes also called artifacts), when the steps to reproduce them are not fully automatic, or for caching purposes, when the build steps to reproduce the output is slow.
So if you have a fully automated process to generate the production files from your dev source files, you only need put the dev files into source control (together with the scripts for creating the production files). If not, establish such a process. Make sure noone has to fiddle around with the production files manually after they have been generated from the source. If you want to deploy “directly” from your VCS, make sure you have a deploy script which pulls the dev source files out of source control, does the “gulpification” and transfers the resulting files over to production in one step.
Of course, if you want to use source control also as a “poor mans backup” or as a cache for your production files, you can set up a second repo for this purpose and put there a copy of the production file structure after generation. This repo will not serve for development, and after it is set up, you should not have to maintain it manually. So make sure there will be no manual steps involved for making backups into this “prod repo” – include the necessary steps into the deploy script which makes the backup automatically. Think about adding a separate backup script if you cannot prohibit manual changes to production after deployment. That way, you can keep the process maintainable even if you have limited resources.
And yes, this should be a strictly separated, second repo, because it has a completely different purpose and a different life cycle than you dev repo. You use it only for backups, not for source control, which is a different process.
9