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 ?