One basic rule of source control is that you need only to put artifacts into the repo (that means: manually created files), everything which can be "compiled" or "generated" does typically not belong there, because it will produce redundancy.
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" 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.