Способ создания веб-приложения с помощью GIT, когда дизайнер не может получить доступ ко всем источникам?

Question

Я хочу применить систему контроля версий в нашей работе, но есть некоторые трудности, потому что графический дизайнер должен иметь доступ только для просмотра шаблонов (smarty) и CSS / JS, поэтому он не может настроить локальную копию веб-приложения. .

Приложение имеет эти элементы, перетаскиваемые в один каталог с именем / front /

Текущая ситуация выглядит следующим образом:

Основной разработчик: собственный сервер apache на рабочей станции, он на 90% работает с PHP.

Второй разработчик: иногда работа (небольшие изменения) по локальной сети (изменение файлов на главном компьютере разработчика)

Дизайнер: работая дома, имеет собственный отдельный домен с клоном сайта (назовем его designerworkarea.com) с FTP-доступом только к шаблонам и CSS.

Разработка / развертывание выглядит следующим образом:

Основной код разработчика и тестирование всего PHP на его компьютере, а затем отправка исходных кодов на основной рабочий сервер (назовем его procutionarea.com) по FTP

Дизайнер работает с файлами "с FTP", поэтому каждое изменение необходимо загружать, и его можно увидеть на сайте designerworkarea.com

Для развертывания внешнего интерфейса администратор на сервере отображает шаблоны представления копии с /server/designerworkarea.com/front на /server/procutionarea.com/front (designerworkarea и productionarea находятся на одном компьютере с Unix)

Конечно, есть некоторая синхронизация (1-2 раза в день), потому что основной разработчик должен добавить новые элементы / шаблоны в интерфейс приложения, которые были стилизованы дизайнером.

Как видите, это какой-то беспорядок. Не было бы проблем, если бы у кого-то мог быть свой собственный стек LAMP с полными исходными текстами - но у дизайнера не может быть доступа к каталогам, отличным от front - поэтому он не может настроить это веб-приложение на своем локальном компьютере.

Как лучше организовать эту рабочую среду с помощью GIT?

Примечание 1: Дизайнер должен иметь возможность видеть свои изменения немедленно, но не «по коммиту», потому что может быть много попыток, прежде чем выполнить какое-то небольшое количество работы, которое должно быть выполнено сразу. И мы не хотим иметь сотни / тысячи коммитов в день.

Примечание 2: В любой момент в шаблонах представления может быть обнаружена ошибка, требующая вмешательства разработчика.

Answer 1

Если вам нужно, чтобы ваш дизайнер все время видел результат своей работы, лучше всего воспользоваться «распределенным» аспектом git и использовать клон вашего репо:

• в качестве промежуточной области для дизайнера, чтобы подтолкнуть к
• в качестве источника для развертывания "промежуточного" веб-сайта (отображается только для дизайнера)

Это позволило бы разработчику:

• делает десятки коммитов до тех пор, пока данная функция не будет выглядеть правильно в отслеживаемой ветви и развернута при каждом коммите на промежуточном веб-сайте
• раздавить его / ее коммиты (в (или merge --squash) специальную ветку, из которой разработчик может вытащить, чтобы вернуть последний дизайн (без получения всех промежуточные коммиты).

Суть в том, что для DVCS (например, Git) вам не нужно использовать только один репо для синхронизации. У вас может быть несколько, каждый с разной ролью.