Uso de LESS y Control de versiones: ¿Debería includese CSS generado en un repository?

Estoy considerando usar LESS para el desarrollo de CSS con el procesamiento lateral del server (o del desarrollo), pero no puedo decidir si debo mantener los files CSS generados en el control de la versión. Hay muchas soluciones con ganchos, pero esto agrega dependencies de software al server. Un gancho podría agregarse localmente para que las áreas de producción y producción en la web obtengan los mismos files. Entonces, la pregunta es:

¿Deben includese los files CSS generados en el control de la versión o no? Tenga en count que algunos frameworks requieren que exista un file CSS por una razón en particular (es decir, los temas de WordPress requieren un file style.css para ser reconocidos).

¡Aclamaciones!

Editar: Cuando digo 'considerando usar MENOS', quiero decir que se convierte en un requisito. Los nuevos desarrolladores no tendrían la opción de usar CSS vainilla después de que la elección sea a favor de LESS.

Has respondido bastante a tu propia pregunta. Depende de cómo implemente su website.

Si el server simplemente va a extraer directamente del repository de Git:

1) Necesita tener un software instalado para generar CSS desde LESS.

2) o necesita include los files CSS en el repository.

Si no está yendo directamente desde el repository en su server web, podría tener un script de construcción que extraiga de git, genere CSS y luego transfiera el contenido a los serveres web, posiblemente excluyendo los files innecesarios de la transferencia.

En mi opinión, Git debe usarse para mantener toda la fuente de un proyecto y ninguno de los "artefactos derivados" (como menciona @thekbb). Los desarrolladores necesitan tener todas las herramientas instaladas para generar esos artefactos derivados durante el desarrollo y la testing. Para la implementación de los serveres de testing y producción, un server de compilation automático debe tomar la fuente y crear solo los files necesarios para la distribución.

En el caso del desarrollo de software, tendría un Makefile con files .C y .H (por ejemplo) en su repository de Git. Los desarrolladores y el server de compilation tienen un comstackdor instalado que creará una biblioteca ejecutable o comstackda. Cuando los files se empaquetan para su distribución, el código fuente no es parte del file.

Para el desarrollo web, tiene files fuente como charts originales, templates HTML y files LESS. Los desarrolladores y el server de compilation pueden ejecutar scripts para generar los activos del sitio (CSS de files LESS, páginas HTML estáticas de templates, imágenes aplanadas en múltiples tamaños / formattings, etc.) Cuando el server de compilation implementa nuevas comstackciones, copy solo los files necesarios por el server, excluyendo los charts fuente, las templates y los files LESS.

Si hay personas que necesitan revisar el contenido del sitio, deben hacerlo en un server de transición. Si eso no es posible, el server de compilation automatizado puede crear un file ZIP en un server interno que pueden download para su revisión.

Controlar los artefactos derivados casi siempre es subóptimo.

Yo voto no para verificar en .css. Solo es cuestión de time que uno de tus compañeros o sucesores compruebe una edición de .css y no de .less. Luego, cuando cambia el .less, se pierde el cambio anterior.

¿Deben includese los files CSS generados en el control de la versión o no?

En teoría, no deberían, pero por razones prácticas, normalmente comprobo en el file css generado. La razón es que simplifica la implementación ya que hago la implementación usando git; No necesitaría tener un comstackdor less instalado en el server y, por lo general, ni siquiera en la máquina desde la que estoy implementando (a diferencia de la máquina en la que estoy desarrollando). Hacer esto podría ser útil si tiene un desarrollador y un implementador por separado, pero a veces también puede ser útil incluso si usted mismo está implementando.

Ahora, hay inconvenientes al hacer esto:

  1. No puedes usar git add --patch (o realmente debes tener mucho cuidado al hacerlo)
  2. No debe modificar el .css directamente; en su lugar, generalmente utilizo un file .css secundario para hacer modificaciones menores sin modificar el file .less o .css primario. También puedes comstackr el file .less directamente en un CSS minificado, para que sea less tentador modificar el CSS generado.
  3. Los desarrolladores tienen que configurar su máquina para usar la herramienta de recompilation automática (como SimpLess o Less.app), por lo que el file .css se actualiza tan pronto como guardan en el file .less. Sin automation, correrá el riesgo de que el CSS no coincida con el less registrado en el file.

Sin embargo, no haría lo mismo al comstackr desde files .C y .H, porque el binary generado para ellos es específico de la plataforma, y ​​también el file .less / .css suele ser una parte muy pequeña de un proyecto web más grande, por lo que el espacio sobrecargado del file adicional es pequeño.

Yo diría que sí, porque ¿qué sucede si desea agregar un desarrollador a su flujo de trabajo y no quiere o no necesita build. ¿Menos? Sería útil para ellos tener acceso solo al file generado.

Buena pregunta. Si puede garantizar que el file CSS se actualice cuando el LESS se actualice, quizás sí, según el comentario de @Scott Simpson. Sospecho que esto sería difícil de garantizar y ¿qué sucede cuando el nuevo desarrollador obtiene una copy de CSS el día en que están desincronizados? Además, por supuesto, y originalmente no había pensado en esto, ¿qué ocurre si el nuevo desarrollador actualiza el file CSS en lugar del MENOR? Si el CSS tiene que ser construido y no es parte de un file, puedo ver less problemas.