Wordpress con Git


21

Estoy haciendo esta pregunta porque busqué en Internet pero no puedo encontrar la solución correcta. En realidad, quiero una solución en la que varios desarrolladores puedan trabajar en un solo proyecto de WordPress sin crear ningún problema entre sí, pero como sabemos que en WordPress todo se mantiene en la base de datos, como qué complemento está activo y cuál no.

Si los desarrolladores instalan complementos en su proyecto local de la forma en que se comunican entre sí, cada uno debe instalar ese complemento o complementos en particular, etc., y alguna falta de comunicación puede romper el sitio de los demás si cada desarrollador empuja / extrae el código.

¿Deberíamos compartir la base de datos también, para compartir la configuración del plugin / temas para que no haya conflictos o pequeños conflictos entre los desarrolladores?

Gracias


55
wp-cli.org ayudará bastante con su flujo de trabajo.
jgraup

1
Si es posible, cambie a jekyll o similar.
Jens Schauder

Jekyll se cuece en github, lo que obviamente funciona bien con git ...
DaveRGP

FWIW, las colisiones y los conflictos no se eliminan por completo cuando se usa algo como Git, solo le permite mantener dichos conflictos fuera de su camino hasta que esté listo para "fusionarlos".

1
¿Pueden todos los desarrolladores compartir una base de datos común alojada públicamente y comprometerse con GIT para el control de versiones?
MonkeyZeus

Respuestas:


18

Git para complementos :

Luego, use Git para administrar composer.jsony los cambios en el complemento TGM.

La parte más difícil es sincronizar la base de datos :

Definitivamente, debemos compartir la base de datos. Reconfigurar la configuración / opciones de un complemento no es una buena idea.

Hay muchos complementos , tanto gratuitos como premium, que pueden ayudar.

Si quieres probar algo manualmente, incorpora wp-cli con la respuesta de @Wyck.


8

Mi equipo se enfrentó a un problema similar. Usamos git para versionar nuestro propio código personalizado, como complementos y el tema que escribimos. Usamos Composer para administrar dependencias como complementos que no escribimos. Verificamos los archivos composer.json y composer.lock en git para mantener a todos sincronizados. Se espera que cada desarrollador extraiga la rama maestra de git y se ejecute composer updateen sus corralitos con frecuencia para que todos estén actualizados.

En la base de datos, los desarrolladores se preocupan principalmente por la configuración, y a menudo utilizamos WP-CLI para mantener la configuración sincronizada. Por ejemplo, tenemos un script de shell que ejecuta un comando WP-CLI para habilitar o deshabilitar complementos por host; algunos complementos solo se usan en nuestro host de almacenamiento de contenido, por ejemplo, por lo que el script se puede ejecutar en cualquier host y solo habilitará el conjunto apropiado en ese host. Algunas configuraciones que requieren demasiado tiempo para la secuencia de comandos solo se documentan y se reproducen manualmente si es necesario.

También tenemos un script perl que clonará completamente la base de datos de nuestro servidor de almacenamiento de contenido en un QA o host de desarrollo. Los desarrolladores pueden usar esto periódicamente si quieren todo el contenido actual, aunque eso suele ser menos importante que tener el código y la configuración. El script realiza estas tareas:

  • volcado mySQL de la base de datos del servidor de almacenamiento de contenido, cambiar los nombres de las tablas, cargar en la base de datos del servidor de destino
  • use wp-cli para cambiar las referencias al servidor de ensayo dentro de la base de datos para referirse al servidor de destino
  • sincronice el directorio de cargas en el servidor de destino con las cargas del servidor de almacenamiento de contenido

Hay algunas soluciones prometedoras para versionar la base de datos que están llegando rápidamente. VersionPress y Mergebot son los dos que conozco y puede haber otros.

Escribí más detalles técnicos sobre cómo configuramos WordPress para trabajar con git y Composer en mi blog. Era necesario ejecutar con el núcleo de WordPress en su propio directorio para hacer una separación limpia entre el código que queremos mantener en git y el núcleo de WordPress. Tratamos a WordPress como una dependencia y lo gestionamos con Composer.


7

La mejor solución que he visto para esto es usar Bedrock ( https://roots.io/bedrock/ ).

Las otras respuestas a esta pregunta (Composer y algo para administrar sus complementos) son buenas respuestas; pero Bedrock proporciona una forma sistemática, respaldada, documentada y continuamente mejorada de hacer esto, que es preferible a la suya.

Además, recuerde que puede tener más de un repositorio de git: uno para su tema, uno para cada complemento personalizado que desarrolle y luego uno 'maestro' para la instalación de Bedrock / Wordpress.


"Bedrock proporciona una forma sistemática, respaldada, documentada y continuamente mejorada de hacer esto, que es preferible a rodar la suya". Puede confirmar, Bedrock es genial! Úselo con Sage (desarrollado por las mismas personas, Roots) y el desarrollo personalizado en un equipo es decentemente manejable. Todavía hay hipo, y la respuesta de @ Dan9 es más completa, ¡pero no puedo cantar las alabanzas de Bedrock lo suficiente!
samrap

Como desarrollador de MVC, estoy de acuerdo, pero el tipo de trabajo en el que hago los sitios de WordPress se basa en gran medida en el front-end, por lo que la configuración de gestión de activos en Sage vale la mala práctica de los globales ocasionales.
samrap

0

Si es absolutamente necesario que tenga los mismos complementos instalados trabajando en el tema o un complemento personalizado, entonces compartiría la base de datos también.

Utilizamos git y composer para mantener actualizados los diferentes entornos de desarrollo. Simplemente realice los últimos cambios y vuelva a ejecutar el compositor y estará listo para comenzar.


0

Para eso, primero que nada, debemos entender la estructura de directorios de WordPress. La estructura de directorios de WordPress no es tan fácil de usar para usar gitcon ella. Por lo tanto, le sugiero que use esto con gituna arquitectura modificada bastante amigable. No, no hay necesidad de entrar en pánico. No necesariamente tiene que crear esto. Hay muchos de esos tipos de repetitivo o sistema estructurado de WordPress por ahí. Simplemente elija uno de ellos y comience a codificar.

Ahora llega al punto de escribir código bien organizado o código mantenible. De hecho, ponemos nuestro código en wp-content\themes\your-themeo wp-content\themes\your-theme. Entonces, en la mayoría de las gitplantillas amigables de WordPress, la wp-contentparte está separada. Y en su mayoría obtienen el repositorio de WordPress a través de composer. Hace que el proyecto completo sea mucho más limpio.

La sincronización de complementos es otra parte importante. Sería mejor si instala su complemento a través de composer. Hace que el código del proyecto sea mucho más limpio. Aquí obtendrá una descripción general de cómo instalar complementos de WordPress composer.

Ahora llega a la parte más crucial, cómo sincronizar la base de datos. Creo que podría hacerse más fácilmente de las siguientes 2 formas:

  • Todo el desarrollador debe usar una base de datos remota. Y con frecuencia crea una copia de seguridad.
  • Automatizar la instalación de importación y exportación de WordPress. Parece complicado, pero no lo es. Solo haz algo de google, espero que puedas hacer eso.

Espero que te ayude.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.