¿Forma de crear una aplicación web con GIT, cuando el diseñador no puede tener acceso a todas las fonts?

Quiero aplicar el sistema de control de versiones en nuestro trabajo, pero hay algunas dificultades, porque el diseñador gráfico solo debe tener acceso para ver templates (smarty) y CSS / JS, por lo que no puede configurar una copy local de la aplicación web.

La aplicación tiene esos elementos arrastrados a un solo directory llamado / front /

La situación actual se ve así:

Desarrollador principal: propio server Apache en la estación de trabajo, trabaja 90% con PHP.

Segundo desarrollador: a veces funciona (pequeños cambios) por la networking local (cambiando los files en la máquina principal del desarrollador)

Diseñador: trabajando en casa, tiene un dominio separado con site-clone (llamémoslo designerworkarea.com) con acceso FTP solo a templates & css.

El desarrollo / implementación se ve así:

Código principal de desarrollador y testing todos los PHP en su máquina, luego coloca las fonts en el server de producción principal (vamos a llamarlo procutionarea.com) por FTP

El diseñador trabaja en files "con FTP", cada cambio se debe cargar y se puede ver en designerworkarea.com

Para implementar frontend, admin en las templates de vista de copy del server desde /server/designerworkarea.com/front a /server/procutionarea.com/front (designworkarea y productionarea están en la misma máquina Unix)

Por supuesto, hay algo de synchronization (1-2 por día) porque el desarrollador principal necesita agregar nuevos elementos / templates al interfaz de la aplicación, que fueron diseñados por el diseñador.

Como pueden ver, esto es un desastre. No habría ningún problema si alguien pudiera tener su propia stack LAMP con fonts completas, pero el diseñador no puede tener acceso a directorys que no sean frontales, por lo que no puede configurar esta aplicación web en su máquina local.

¿Cuál será la mejor manera de organizar este entorno de trabajo con GIT?

Nota 1: El diseñador debería tener la posibilidad de ver sus cambios de forma inmediata, pero no mediante 'commit', ya que puede haber muchos bashs antes de completar una pequeña cantidad de trabajo que debe realizarse de inmediato. Y no queremos tener cientos / miles de compromisos por día.

Nota 2: En cualquier momento puede haber un error encontrado en las templates de visualización que requiere la intervención del desarrollador.

Si necesita que su diseñador vea en todo momento el resultado de su trabajo, lo mejor es aprovechar el aspecto "Distribuido" de git, y tener un clon de su repository utilizado:

  • como un área de preparación para que el diseñador empuje a
  • como fuente para implementar un website de "preparación" (visible solo por el diseñador)

Eso le permitiría al diseñador:

  • realice decenas de confirmaciones hasta que una determinada característica se vea correctamente en una sucursal supervisada e implementada en cada confirmación en el website provisional
  • squash his / her commits (en (o merge --squash to) una twig especial que el desarrollador puede extraer para recuperar el último layout (sin get todas las confirmaciones intermedias).

El punto es: con un DVCS (como Git), no tienes que usar solo un report para la synchronization. Puede tener varios, cada uno con un rol diferente.