Контроль версий сайта: файлы разработки и разработки

Я пытаюсь придумать лучший способ контроля версий проектов нашего сайта. Имейте в виду, что я всего лишь внешний разработчик, поэтому у меня нет глубоких знаний о VCS.

Рабочие процессы меняются, и прежние привычки управления версиями устаревают. Основная проблема в том, что для каждого сайта есть 2 массива интерфейсных файлов.

Среда разработки (меньше файлов, несжатые файлы js, изображения и т. Д.). Среда сборки "gulpified" (все сжато и не читается людьми).

Но вы не можете продать сайт с его исходными файлами. Ну, это не совсем правильно.

Существует решение, заключающееся в том, чтобы иметь 2 репозитория: одна сборка, одна dev, с gulp, отправляющей файлы dev в каталог build. Но это трудно поддерживать с небольшими компаниями, я не думаю, что это здорово. Это создает много репозиториев, и людям приходится справляться с несколькими репо, иногда даже с одним репозиторием SVN, возникают проблемы.

Таким образом, есть также решение иметь 1 репо: исходные файлы и файлы prod в одном SVN. Но тогда необходимо удалить исходные файлы, когда веб-сайт переходит с локального сервера разработки на рабочий сервер (поэтому в одном репозитории находятся разные файлы в зависимости от его местоположения, разработки или производства). Из того, что я слышал, это не хорошо

Как правильно управлять рабочим процессом внешнего интерфейса gulp в отношении системы контроля версий?

Одно из основных правил управления исходным кодом заключается в том, что в репозиторий (исходные исходные файлы) нужно только помещать написанные вручную артефакты , все, что может быть «скомпилировано» или «сгенерировано», не должно храниться там, поскольку это приведет к избыточности. , Один может (необязательно) хранения промежуточных результатов / части процесса сборки в репозитории (иногда также называемые артефакты), когда шаги , чтобы воспроизвести их не полностью автоматически, или для кэширования целей, когда шаги сборки для воспроизведения на выходе будет медленным ,

Поэтому, если у вас есть полностью автоматизированный процесс создания производственных файлов из ваших исходных файлов dev, вам нужно всего лишь поместить файлы dev в систему управления версиями (вместе со сценариями для создания производственных файлов). Если нет, установите такой процесс. Убедитесь, что никто не должен возиться с рабочими файлами вручную после того, как они были сгенерированы из источника. Если вы хотите развернуть «напрямую» из своей VCS, убедитесь, что у вас есть сценарий развертывания, который выводит исходные файлы dev из-под контроля исходного кода, выполняет «gulpification» и передает полученные файлы в производство за один шаг.

Конечно, если вы хотите использовать управление исходным кодом также в качестве «резервной копии плохого человека» или в качестве кеша для ваших производственных файлов, вы можете создать для этого второе хранилище и поместить туда копию структуры производственных файлов после генерации. Этот репо не будет использоваться для разработки, и после его настройки вам не нужно будет поддерживать его вручную. Поэтому убедитесь, что не будет никаких ручных шагов для создания резервных копий в этом «prod repo» - включите необходимые шаги в сценарий развертывания, который выполняет резервное копирование автоматически. Подумайте о добавлении отдельного сценария резервного копирования, если вы не можете запретить ручные изменения в рабочей среде после развертывания. Таким образом, вы можете поддерживать процесс сопровождения даже при ограниченных ресурсах.

И да, это должен быть строго отделенный второй репо, потому что он имеет совершенно иную цель и иной жизненный цикл, чем ваш репо. Вы используете его только для резервного копирования, а не для управления исходным кодом, что является другим процессом.