Flujo de trabajo GIT de desarrollador único (pasar de FTP directo)

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.

git version-control

— melat0nin
fuente

Lo que debe recordar acerca de git (o cualquier otro VCS distribuido) es que todos los repositorios son, al menos técnicamente, pares: su repositorio local es tan "real" como el del servidor en vivo, o el repositorio de respaldo. Se trata de sus políticas de flujo de trabajo que les dan estructura - por lo que si realmente quiere seguir haciendo el trabajo primaria en el servidor en vivo, se puede ...

— comingstorm

Gracias, es bueno saberlo. La flexibilidad inherente de Git hace que sea difícil encontrar un punto de partida de 'mejores prácticas': ¡eso es una fortaleza del POV de un usuario experimentado pero una debilidad discutible de un novato!

— melat0nin

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).

— ZweiBlumen
fuente

¡Gracias por su respuesta! ¿Eso significa que extrae la instantánea a su máquina local, realiza y confirma cambios y luego realiza una solicitud de extracción desde el servidor en vivo (mediante SSHing in)? ¿Qué pasa si el cambio es realmente pequeño? ¿Ejecutas un servidor web local para el desarrollo? (No pude pasar por ese proceso para cambios simples de CSS ... ¡Me volvería loco!)

— melat0nin

Para un cambio menor de CSS, haría el cambio directamente en el servidor y luego lo confirmaría en el repositorio desde el servidor. Cuando tengo que hacer una cantidad de trabajo más seria en el sitio, entonces actualizo el sitio en mi máquina de desarrollo con la última versión del sitio desde el repositorio. Supongo que realmente no importa dónde realice el cambio (servidor o máquina de desarrollo) siempre que lo confirme en el repositorio.

— ZweiBlumen

Entonces, ¿qué herramientas utilizas para esto? ¿FTP para hacer que el archivo cambie directamente en el servidor, luego se abre una sesión SSH en segundo plano para realizar las confirmaciones al servidor Git de vez en cuando?

— melat0nin

Sí, eso es básicamente todo. De hecho, uso Subversion. Tenemos sitios en Windows y servidores Linux. En el escritorio remoto de Windows I en ellos, realice el cambio de CSS y confirme con TortoiseSVN. En Linux utilizo una sesión SSH y vim para hacer los cambios (pero también puede enviar sus cambios por FTP, supongo).

— ZweiBlumen

Fui con su sugerencia de editar en el servidor y luego me comprometí desde allí a través de SSH, lo que he estado haciendo durante unos días. Parece funcionar muy bien, gracias!

— melat0nin

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.

— Jan Hudec
fuente

Seguiría estos pasos:

Configure el servidor remoto con un par de claves público / privado adecuado para push / pull remoto
Configurar dos ramas de prueba y lanzamiento
Desarrollar localmente con un entorno de prueba en la rama de prueba
Cuando esté satisfecho, fusione con la rama de lanzamiento y empuje al servidor remoto
Enganche en el servidor remoto para actualizar a la última versión de lanzamiento

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.

— Spencer Rathbun
fuente

Entonces, lo entiendo correctamente: hay dos servidores (1) para Git, (2) servidor web en vivo y una máquina de desarrollo local. ¿Dev se realiza localmente y luego se envía al servidor Git que tiene un gancho para actualizar el servidor en vivo?

— melat0nin

@ melat0nin Esa es una forma de hacerlo. También puede hacer que el servidor en vivo extraiga del servidor git como un trabajo cron. O puede tener 2 máquinas. La máquina de desarrollo local y el servidor web de producción en vivo. De esa manera, al enviar el repositorio de la máquina de desarrollo a la máquina de producción, se actualiza a la rama de lanzamiento más reciente cada vez que se presiona.

— Spencer Rathbun