Sé que esta pregunta es un poco más antigua, sin embargo, como no he visto esto como respuesta aquí, me gustaría compartir lo que normalmente hago para configuraciones e implementaciones basadas en git de un solo sitio y está funcionando muy bien, también con el trabajo desde múltiples dispositivos, ubicaciones y con múltiples desarrolladores (todos tienen sus propios repositorios locales en los que operan, ya que es común para git).
Puedo sugerir con entusiasmo la siguiente configuración:
También se describe en (si necesita un segundo recurso para entenderlo):
Básicamente funciona (con al menos tres repositorios):
- poner el sitio web en el host en vivo bajo git,
- cree un nuevo repositorio de git desnudo en el host en vivo.
- Y luego bifurca desde el repositorio desnudo a tus repositorios de desarrollo local de git.
Cuando el trabajo está hecho, empujas contra el repositorio desnudo remoto desde el que has clonado. El repositorio simple tiene ganchos para sincronizarse con el repositorio en vivo (en los códigos anteriores llamados prime ).
Como configuración específica de Wordpress en el repositorio, tengo esto .gitignore:
# uploads are data, excluded from source tree
wp-content/uploads/
El resto incl. la configuración del complemento y el tema que mantengo bajo control de versión / configuración. Esto me permite rastrear fácilmente los cambios y revisar el código antes de usarlo en vivo. También puedo fusionarme más fácilmente contra árboles remotos con mis propios cambios. Eso es especialmente útil contra el núcleo de Wordpress que está disponible en Github .
Esto funciona bastante bien para la mayoría de mis necesidades de Wordpress. El repositorio simple evita que empujes cambios conflictivos. También se sincroniza con una copia remota antes de actualizar el sitio en vivo. Eso significa que la actualización del sitio en vivo suele ser bastante rápida. Debido a los enlaces, incluso puede llamar a los enlaces de actualización de Wordpress después si lo desea.
Si no he experimentado cuánto se puede mejorar con los ganchos de Github, pero normalmente no los necesito ya que el código está bajo control de versión local, no Github.
Para configurar dicho sistema por primera vez, debe tomarse un tiempo para evaluar si tiene todas las herramientas disponibles en su host remoto:
- Acceso SSH
- GIT
- Un directorio privado en el que puede colocar archivos y subdirectorios (por ejemplo, para su repositorio de git)
El tiempo de configuración por primera vez debe ser posible dentro de una dos horas incl. todo el entorno y primero publicas push.
Dependiendo de su host, es posible que también desee proteger el .gitdirectorio del acceso web. Aquí hay un .htaccesscódigo de ejemplo que incluso lo hace teniendo Wordpress dentro de un subdirectorio, lo que deja espacio en el repositorio no publicado en línea (útil):
Options -Indexes
# fix trailing slash for .git / make it disappear + .gitignore and similar files.
RedirectMatch 404 ^/\.git(.*)$
# mask 403 on .ht* as 404
<Files ~ "^\.ht">
Order Deny,Allow
Allow from all
Satisfy All
Redirect 404 /
</Files>
RewriteEngine On
RewriteBase /
# map everything into public and set environment var
# to tag the request being valid
RewriteCond %{ENV:REDIRECT_sitealias} !set
RewriteRule ^(.*)$ /public/$1 [E=sitealias:set,L]
En resumen, todo lo que no está dentro del directorio público no está en línea. Dentro del directorio público puede estar la base de código de WordPress, por ejemplo, para lo .htaccessque necesita entonces:
RewriteEngine On
# mask as 404 if directly accessed
RewriteCond %{ENV:REDIRECT_sitealias} !set
RewriteRule .* - [L,R=404]
Esto impide el acceso directo al público . Parte de este .htaccess -foo se puede encontrar aquí: Las solicitudes a .htaccess deben devolver 404 en lugar de 403 . Para las variables de entorno, debe probar si eso funciona en su entorno. También debe decidir si lo pone bajo control de versión o no.
Si tiene más control sobre el alojamiento, puede hacer más cosas aquí (y de manera diferente / más optimizada), los ejemplos anteriores están dirigidos a entornos de alojamiento compartido típicos (que ofrecen GIT, algunos usuarios dicen que puede instalarlo fácilmente como suyo) bueno, normalmente les pido a mis anfitriones que me lo proporcionen porque prefiero que si se cuidan, eso es lo que les pago).
En el lado negativo, esto tiene algunos de los problemas comunes también descritos en las otras respuestas. Una cosa de la que no estoy orgulloso es que lo que funciona es darle al host de desarrollo un cambio en su archivo de host para que el servidor de la base de datos apunte a la copia de desarrollo. Para que pueda mantener una configuración de base de datos. No es realmente genial esp. por las credenciales
Copias de seguridad automáticas
Sin embargo, normalmente no me importa mucho aquí, sino que tengo copias de seguridad diarias que se ejecutan en los sistemas remotos, que se almacenan gradualmente en otra ubicación remota. Eso es fácil y barato y le permite restaurar tanto la instalación de Wordpress como las cargas de archivos, la base de datos y el repositorio de git. También para mis comandos de copia de seguridad podría no estar perfectamente bien, pero esos funcionan para mí:
mysql: mysqldump --host=%s -u %s --password=%s %s| gzip > %s
git : git gc
git bundle
files: tar --force-local -czf %s %s
Lo que sugiero aquí es que mantenga los procesos alrededor de su instalación de Wordpress fuera de Wordpress. Deben ejecutarse en un sistema específico, por lo que normalmente no los tiene dentro de la aplicación (por ejemplo, la aplicación puede fallar, pero necesita que estos continúen funcionando).
Habilitado para trabajo en equipo
Otro buen beneficio es que su sitio ya está habilitado para el trabajo en equipo. Gracias al repositorio simple adicional, no puede hacer mucho mal e incluso puede compartir ramas remotas aparte de una rama maestra o en vivo con sus colegas.