Controle de versão de um site: arquivos front-end de desenvolvimento / produção

Estou tentando pensar em uma maneira melhor de controlar a versão dos projetos de nosso site. Lembre-se de que sou apenas um desenvolvedor front-end, por isso não tenho um conhecimento profundo do VCS.

Os fluxos de trabalho estão mudando e os hábitos de controle de versões anteriores se tornam obsoletos. O principal problema é que existem 2 matrizes de arquivos front-end para cada site.

O ambiente de desenvolvimento (menos arquivos, js descompactados, imagens etc.). O ambiente de construção, "gulpificado" (tudo compactado e não legível por humanos).

Mas você não pode vender um site com seus arquivos de origem. Bem, não parece certo.

Existe a solução de ter 2 repositórios: um build, um dev, com o gulp enviando arquivos dev para o diretório build. Mas é um aborrecimento para manter, com pequenas empresas não acho tão bom assim. Ele cria muitos repositórios e as pessoas precisam gerenciar vários repositórios, às vezes até com um repositório svn, surgem problemas.

Portanto, há também a solução de ter 1 repo: os arquivos de origem e os prod no mesmo svn. Porém, é necessário remover os arquivos de origem quando o site passar do servidor de desenvolvimento local para o servidor de produção (para que haja arquivos diferentes em um único repositório, com base em sua localização, desenvolvimento ou produção ..). Pelo que ouvi, não é bom

Qual é a maneira correta de gerenciar um fluxo de trabalho de front-end gulp em relação ao sistema de controle de versão?

Uma regra básica do controle de origem é que você só precisa colocar artefatos escritos manualmente no repositório (os arquivos de origem originais), tudo o que pode ser "compilado" ou "gerado" não precisa ser armazenado lá, porque produzirá redundância . Um pode (opcionalmente) armazenar saídas / partes de um processo de construção intermediários em um repo (às vezes também chamados de artefatos), quando as etapas para reproduzi-los não são totalmente automático, ou para fins de armazenamento em cache, quando as etapas de construção para reproduzir a saída é lenta .

Portanto, se você tiver um processo totalmente automatizado para gerar os arquivos de produção a partir dos arquivos de origem do desenvolvedor, você só precisará colocar os arquivos de desenvolvimento no controle de origem (junto com os scripts para criar os arquivos de produção). Caso contrário, estabeleça esse processo. Certifique-se de que ninguém precise mexer nos arquivos de produção manualmente depois de gerados a partir da fonte. Se você deseja implantar "diretamente" a partir do seu VCS, verifique se possui um script de implantação que retire os arquivos de origem do controle de origem, faça a "gulpificação" e transfira os arquivos resultantes para a produção em uma única etapa.

Obviamente, se você quiser usar o controle de origem também como um "backup pobre do homem" ou como um cache para seus arquivos de produção, poderá configurar um segundo repositório para esse fim e colocar uma cópia da estrutura do arquivo de produção após a geração. Esse repositório não servirá para desenvolvimento e, depois de configurado, não será necessário atualizá-lo manualmente. Portanto, verifique se não haverá etapas manuais envolvidas para fazer backups neste "repositório de produtos" - inclua as etapas necessárias no script de implantação que faz o backup automaticamente. Pense em adicionar um script de backup separado se não puder proibir alterações manuais na produção após a implantação. Dessa forma, você pode manter o processo de manutenção, mesmo se você tiver recursos limitados.

E sim, esse deve ser um segundo repo estritamente separado, porque tem um objetivo completamente diferente e um ciclo de vida diferente do repo dev. Você o usa apenas para backups, não para controle de origem, que é um processo diferente.