git - para - wordpress trac

Git Workflow con WordPress-Localhost to Live

Question

Tengo una pregunta de flujo de trabajo de WordPress básica pero común.

Flujo de trabajo actual

1. Desarrollo todo localmente
2. Archivos FTP (y volcado de la base de datos) hasta el servidor para mostrar al cliente
3. Realice los cambios solicitados localmente
4. Los archivos FTP (y el volcado de la base de datos) vuelven a subir al servidor
5. Más ediciones locales
6. FTP (y volcado de base de datos) de nuevo
7. Enjuague y repita

Esto se ha convertido en un dolor de monstruo. Tiene que haber una mejor manera

Flujo de trabajo sospechoso de Git

1. La copia local será mi ''maestro''
2. ''Empujar'' archivos hacia algún lugar
3. ''Extraiga'' archivos de este lugar en el medio a mi servidor en vivo / prueba

Creo que tengo una idea de cómo debería hacerse conceptualmente, pero no sé cómo debería hacerse prácticamente. ¿Debería usar un repositorio privado de Github en el medio? ¿Hay alguna manera de que mi sitio Live "tire" directamente de mi repositorio de localhost?

Disculpas si esto parece elemental o muerto de muerte, pero he buscado y no he encontrado una guía básica "Así se debe ver tu flujo de trabajo".

¡Con gracias!

Terry

Answer 1

Estoy empezando a configurar ese flujo de trabajo para Wordpress. Ya lo tengo trabajando para algunos otros proyectos web.

Estoy usando la herramienta gitolite (https://github.com/sitaramc/gitolite/wiki/) para administrar repositorios simples (repositorios sin un registro local) en una ubicación central, y luego activar un enlace de actualización en gitolite cuando se trata de una rama empujado desde la ubicación de desarrollo.

Este enganche se envía al servidor en vivo (o la cuenta del cliente o lo que sea) con una clave privada compartida almacenada en el servidor de implementación, y realiza un git pull desde public_html o cualquier ubicación que tenga al servicio de su instalación de Wordpress.

Esto se hace usando una entrada de solo lectura en el archivo de configuración gitolite que es conf / gitolite.conf en el repositorio de configuración local. (Gitolite usa un repositorio de git para administrar sus archivos de configuración)

repo wp-versions
RW+ = tmzt
R = server1
R = server2

La primera es mi clave pública primaria, que se almacena keydir / tmzt.pub en el mismo repositorio (el mismo formato que .ssh / authorized_keys). Los otros dos son servidores web en vivo que tendrán acceso de solo lectura al repositorio. Agregue las tres claves a keydir y asegúrese de confirmar y presionar. Los cambios se realizarán automáticamente en la instalación de gitolite. (Las claves del servidor son compartidas por múltiples usuarios y copiadas al archivo .ssh / id_rsa de cada usuario, pero esto podría ser de datos www, si lo prefiere).

RW + significa que mi usuario principal ha leído, escrito y puede actualizar ramas de avance rápido (útiles para revertir las confirmaciones en el servidor).

Answer 2

Parece que no estás usando el control de versiones en absoluto. Es una buena idea que comiences. Acabo de convertirme de SVN a Git, y estoy haciendo más o menos lo que estás haciendo en un nivel superior. Comencemos con tus objetivos:

1. Obtener control de versión
2. Establecer algún tipo de despliegue web a través de Git
3. Aloje el control de versiones de forma remota

La gente te dirá que Git no es una herramienta de despliegue web, es posible que tenga razón, pero hasta ahora funciona bien para mí, e hice algo similar. Por suerte para ti, practiqué en una instalación de Wordpress. Estos son los pasos que tomé.

1. Lo tengo todo con la configuración de Git y lo instalo en lo que respecta al cliente.
2. Descargué la última versión de Wordpress en una instalación simple.
3. git init la instalación base sin modificaciones
4. Ramificó el maestro en "dev" y "en vivo"
5. Trabaja de forma local, cometiendo en "dev", luego una vez que se realizan los cambios, se fusionan para vivir.

Ahora, lo que terminé yendo y gitolite fue crear una gitolite virtual de servidor gitolite y usarla como mi anfitrión, esto efectivamente reemplazó a Github en su ejemplo. Creo que conoces el valor de un repositorio remoto: definitivamente seguiría esa ruta.

Voy a dar marcha atrás por un segundo en el paso 2 de mis recomendaciones. Debes mantener la versión estándar de Wordpress en el maestro para que puedas actualizar el núcleo y ver cómo funciona con tu código personalizado, en lugar de actualizar el núcleo en algo así como una de tus ramas y todo lo demás. Esto ha sido muy conveniente para mí, y algo que definitivamente voy a usar en proyectos más grandes como Magento.

Ok, volviendo a la implementación. Puede poner un cliente de git en su servidor web y hacer que lo pull de su sucursal en el flujo de trabajo, pero debe tener en cuenta algunas consideraciones especiales de planificación. Es muy probable que sus archivos prod sean diferentes a sus archivos dev en ciertos lugares, particularmente en la configuración (base de datos, etc.); querrá asegurarse de que esos archivos estén en .gitignore por lo que no está arrancando las configuraciones dev en su entorno de prod

He resumido todo lo que la gente me decía cuando comencé a trabajar en esto, así que espero que ayude. Una vez más, estoy un poco pasado donde estás, así que si alguien tiene correcciones / optimizaciones, no dude en comentar.