我正在尝试一种更好的方式来控制我们的网站项目的版本。请记住，我只是一个前端开发人员，所以我对VCS并不了解。
工作流程在变化，过去的版本控制习惯变得过时。主要问题是每个网站都有2个前端文件阵列。
开发环境（较少的文件，未压缩的js，图像等）。构建环境“变得糊涂”（一切压缩且人类无法读取）。
但是您不能出售带有源文件的网站。好吧，感觉不太正确。
有两个解决方案的解决方案：一个构建，一个开发，并用gulp发送dev文件到构建目录。但是，对于小型公司而言，维护起来很麻烦，我认为这不是那么好。它创建了很多回购协议，人们不得不管理多个回购协议，有时甚至需要一个svn回购协议，都会出现问题。
因此，还有一种解决方案，即拥有1个repo：同一svn中的源文件和prod文件。但是，当网站从本地开发服务器转到生产服务器时，需要删除源文件（因此，根据其位置，开发或生产，单个存储库中有不同的文件。）。据我所知不好
关于版本控制系统，管理gulp前端工作流的正确方法是什么？
Answers:
源代码控制的一个基本规则是，您只需要将人工编写的工件放入存储库（原始源文件）中，就可以将“可编译”或“生成”的所有内容存储在此处，因为这会产生冗余。一个可以（可选地）存储中间输出/构建过程的部分在一个回购（有时也称为工件），当重现的步骤它们不是完全自动的，或用于高速缓存的目的，当所述构建步骤重现输出是慢。
因此，如果您有一个完全自动化的过程来从您的dev源文件生成生产文件，则只需将dev文件放入源代码管理中（连同用于创建生产文件的脚本）。如果没有，请建立这样的过程。确保从源生成产品文件后，没有人要手动摆弄产品文件。如果要从VCS“直接”部署，请确保您具有一个部署脚本，该脚本可以将dev源文件从源代码控制中拉出，进行“ gulpification”并将一步生成的文件传输到生产环境中。
当然，如果您还想将源代码管理用作“穷人备份”或用作生产文件的缓存，则可以为此设置第二个存储库，并在生成后将生产文件结构的副本放置在那里。此存储库将不用于开发，并且在设置后，您不必手动维护它。因此，请确保没有涉及将备份制作到此“产品仓库”中的手动步骤 -将必要的步骤包括到自动生成备份的部署脚本中。如果不能禁止部署后手动更改生产，请考虑添加单独的备份脚本。这样，即使资源有限，也可以使过程可维护。
是的，这应该是严格分开的第二个存储库，因为它的用途和生命周期与开发存储库完全不同。您仅将其用于备份，而不用于源代码控制，这是一个不同的过程。