Estoy tratando de decidir si mudarme a VCS es sensato para mí. Soy un desarrollador web único en una pequeña organización (5 personas). Estoy pensando en VCS (Git) por estas razones: control de versiones, copia de seguridad fuera del sitio, repositorio de código centralizado (se puede acceder desde casa).
En este momento trabajo en un servidor en vivo en general. Entro FTP, hago mis ediciones y las guardo, luego vuelvo a cargarlas y las actualizo. Las ediciones son generalmente a archivos de tema / plugin para CMS (por ejemplo, concrete5 o Wordpress). Esto funciona bien pero no proporciona respaldo ni control de versiones.
Me pregunto cómo integrar mejor VCS en este procedimiento. Consideraría configurar un servidor Git en el servidor web de la compañía, pero no tengo claro cómo enviar los cambios a las cuentas del cliente (generalmente VPS en el mismo servidor); en este momento, simplemente inicio sesión en SFTP con sus detalles y hago Los cambios directamente.
Tampoco estoy seguro de qué representaría sensiblemente un repositorio: ¿el sitio web de cada cliente obtendría el suyo?
Cualquier idea o experiencia sería realmente útil. No creo que necesite toda la potencia de Git de ninguna manera, pero el control de versiones básico y el acceso de facto a la nube serían realmente útiles.
EDITAR: Lo he reducido a las dos opciones que parecen más sensatas. El primero se basa en la respuesta de ZweiBlumen , mediante la cual se realizan ediciones en el servidor en vivo y se envían desde allí al servidor Git (externo). Esto tiene la ventaja de que mi flujo de trabajo no cambiará mucho (existe el paso adicional de realizar los commits, pero por lo demás es idéntico).
La segunda opción es trabajar localmente usando XAMPP, luego confirmar los cambios desde la máquina local. Solo cuando el sitio se activa, subo el artículo terminado al servidor web desde la máquina local (inmediatamente después del compromiso final con Git). En teoría, esto parece estar bien, pero si el sitio requiere enmiendas y lo hago en el servidor en vivo (como lo hago habitualmente), entonces tendré que copiar manualmente los archivos modificados en mi repositorio local, luego confirmar esos cambios en el Servidor Git. Esto parece excesivamente complejo y quizás es una desviación demasiado grande de mi flujo de trabajo actual.
Creo que a fin de cuentas le daré una oportunidad a la opción n. ° 1 y veré cómo me llevo.
fuente
Respuestas:
Lo que hago (con Subversion, pero también funcionará con Git) es comprometer todo en un repositorio de Subversion, pero obviamente dividirlo en proyectos, ramas, etiquetas según sea necesario. Luego reviso estos repositorios en el servidor en vivo. Por lo tanto, cuando realizo un cambio en mi máquina de desarrollo y lo confirmo en el repositorio, a menudo se trata simplemente de actualizar la copia desprotegida en el servidor en vivo para que los cambios se realicen. La ventaja adicional es que si necesito hacer una solución rápida en el servidor en vivo, lo confirmo en el repositorio del servidor y actualizo la copia de trabajo en mi máquina de desarrollo.
Estoy seguro de que hay otras formas de gestionar esto, pero me parece bastante sencillo y estoy exactamente en la misma situación que usted: desarrollador único en una pequeña organización (4 personas).
fuente
Es bastante fácil crear un
post-updateenlace , que actualiza automáticamente (git archivese prefiere exportar con por razones de seguridad) el directorio de datos del servidor web cuando ingresa a una rama específica.Entonces, tenga un repositorio git configurado en algún lugar (por razones de seguridad, lo pondría en un servidor diferente al de la web) con tal gancho. Por supuesto, necesitará un servidor de prueba para probar cambios más grandes, que pueden estar en su máquina local o actualizarse presionando a una rama diferente. En cualquier caso, puede omitirlo para la ortografía trivial y las correcciones CSS simplemente haciendo commit y push.
fuente
Seguiría estos pasos:
Configure un repositorio por sitio web para evitar que se acumulen entre sí. Las ramas separadas le permiten evitar que el bloqueo de la versión "buena" actual pase a lo que está trabajando actualmente, que puede o no funcionar.
fuente