J'essaie de penser à une meilleure façon de contrôler la version de nos projets de site Web. Gardez à l'esprit que je ne suis qu'un développeur front-end, donc je n'ai pas une connaissance approfondie de VCS.
Les workflows changent et les anciennes habitudes de contrôle des versions deviennent obsolètes. Le principal problème est qu'il existe 2 tableaux de fichiers frontaux pour chaque site Web.
L'environnement de développement (moins de fichiers, js non compressés, images, etc.). L'environnement de construction, "gulpified" (tout compressé et non lisible par les humains).
Mais vous ne pouvez pas vendre un site Web avec ses fichiers source. Eh bien, cela ne semble pas tout à fait correct.
Il y a la solution d'avoir 2 dépôts: un build, un dev, avec gulp envoyant des fichiers dev au répertoire de build. Mais c'est un problème à entretenir, avec les petites entreprises, je ne pense pas que ce soit génial. Cela crée beaucoup de repos, et les gens doivent gérer avec plusieurs repos, parfois même avec un seul dépôt svn, des problèmes surviennent.
Il y a donc aussi la solution d'avoir 1 repo: les fichiers source et les fichiers prod dans le même svn. Mais ensuite, il est nécessaire de supprimer les fichiers source lorsque le site Web passe du serveur de développement local au serveur de production (il y a donc différents fichiers dans un même référentiel, en fonction de son emplacement, de son développement ou de sa production ..). D'après ce que j'ai entendu, ce n'est pas bon
Quelle est la bonne façon de gérer un flux de travail frontal Gulp en ce qui concerne le système de contrôle de version?