Despliegue con Git: despliega tu página web automáticamente con control de versiones
Subir archivos a mano por FTP es una forma de trabajar de otra época. Es lenta, propensa a errores y no ofrece control de versiones. El despliegue con Git moderniza este proceso: haces push de tu código y los cambios salen en directo de forma automática. En esta guía completa te explico cómo configurar el despliegue con Git y sacarle el máximo partido.
¿Por qué pasar de FTP al despliegue con Git?
El flujo de trabajo tradicional de muchos desarrolladores y propietarios de páginas web es sencillo, pero problemático. Editas los archivos en local, abres un cliente FTP, navegas hasta la carpeta correcta del servidor, subes los archivos modificados y esperas que todo funcione. Este flujo de trabajo tiene problemas de base.
Es fácil olvidarse de archivos. Cambias cinco archivos, subes cuatro y te preguntas por qué la web no funciona. También es fácil subir la versión equivocada. Pruebas en local, olvidas guardar, subes una versión antigua y no ves los cambios. No hay historial de lo que has modificado y cuándo. Si algo se rompe, no puedes volver con facilidad a una versión que funcione.
El despliegue con Git resuelve todos estos problemas. Git registra qué archivos han cambiado, así que no se te pasa nada. Cada cambio es un commit con una descripción, de modo que sabes exactamente qué hiciste y cuándo. Tienes todo el historial disponible para volver atrás si hace falta. Y el proceso de despliegue es coherente y repetible.
¿Qué enfoques existen para el despliegue con Git?
Git push a un remote en el servidor
El método más directo es configurar un remote de Git en tu servidor de producción. Haces push a este remote y un hook se encarga de aplicar los cambios en el directorio de tu página web. Esto requiere acceso SSH a tu servidor y algo de configuración, pero después es muy sencillo de usar.
Pipelines de CI/CD
Los pipelines de integración continua y despliegue continuo ofrecen más control y flexibilidad. Plataformas como GitHub Actions, GitLab CI o Bitbucket Pipelines detectan cuándo haces push de tu código a tu repositorio. Después ejecutan una serie definida de pasos: lanzar las pruebas, compilar los assets y, por último, desplegar en tu servidor.
Este enfoque es más potente que un simple git push. Puedes ejecutar pruebas automáticamente antes de que el código salga en directo. Puedes añadir pasos de compilación para los assets del frontend. Puedes desplegar en varios entornos. Pero requiere más configuración y conocimientos de los conceptos de CI/CD.
Hosting con integración de Git incorporada
Algunos proveedores de hosting integran el despliegue con Git directamente en su plataforma. Conectas tu repositorio de GitHub o GitLab y cada push a una rama concreta activa el despliegue de forma automática. Cloudways, Kinsta, Vercel y Netlify son algunos ejemplos. Es la opción más cómoda si tu hosting la admite.
Herramientas de despliegue
Herramientas como Deployer para PHP, Capistrano para Ruby o Envoy para Laravel ofrecen funciones avanzadas de despliegue. Defines las tareas de despliegue en archivos de configuración y la herramienta las ejecuta. Es útil para despliegues complejos con varios pasos, pero excesivo para webs sencillas.
Configurar el despliegue con Git en un VPS paso a paso
Paso uno: instalar Git en el servidor
Entra en tu servidor por SSH. Instala Git si todavía no está presente. En Ubuntu o Debian se hace con apt update seguido de apt install git. En CentOS o RHEL se usa yum install git. Comprueba la instalación con git version.
Paso dos: crear un repositorio bare
Crea un directorio para tu repositorio de Git, por ejemplo /var/repo/mysite.git. Ve a este directorio e inicializa un repositorio bare con git init bare. Un repositorio bare contiene solo datos de Git, sin directorio de trabajo con archivos. Sirve únicamente para recibir pushes.
Paso tres: configurar el hook post-receive
La magia está en el hook post-receive. Es un script que Git ejecuta después de recibir un push. Crea el archivo hooks/post-receive en tu repositorio bare. Este script debe extraer el código al directorio de tu página web.
Un script básico define variables para tu directorio de destino y la ubicación del repositorio. Lee las referencias recibidas y comprueba si se trata de la rama correcta. Si es así, extrae el código al directorio de destino. Haz el script ejecutable con chmod plus x.
Paso cuatro: añadir el remote a tu repositorio local
En tu proyecto local, añade un nuevo remote que apunte a tu servidor. Usa git remote add production con la dirección SSH de tu repositorio. Puedes darle al remote el nombre que quieras; production describe bien adónde va el código.
Paso cinco: desplegar
Ahora puedes desplegar con un comando sencillo: git push production main. Git envía tus commits al servidor, el hook post-receive se ejecuta y tu código aparece en el directorio de la página web. Cada push posterior funciona de la misma manera.
Automatizar el despliegue con GitHub Actions
GitHub Actions ofrece una forma potente de automatizar el despliegue. Creas un archivo de workflow en tu repositorio, en .github/workflows. Este archivo YAML define cuándo se ejecuta el workflow y qué pasos se realizan.
Un workflow de despliegue básico se activa con los pushes a la rama main. El job se ejecuta en un runner de Ubuntu, extrae el código y se conecta por SSH a tu servidor para ejecutar un git pull. Configuras las credenciales SSH como secrets en los ajustes de tu repositorio de GitHub para que estén seguras.
La ventaja de GitHub Actions frente a un git push directo es que puedes añadir pasos adicionales. Ejecuta primero las pruebas para asegurarte de que el código funciona. Compila los assets del frontend con npm o webpack. Envía una notificación a Slack cuando el despliegue termine bien o falle. Las posibilidades son muy amplias.
Buenas prácticas para un despliegue con Git seguro y fiable
Mantén las credenciales fuera de tu repositorio
Esto es fundamental y no admite discusión. Las contraseñas, las API keys, las credenciales de las bases de datos y otros secrets no deben estar en tu repositorio de Git. Aunque tu repositorio sea privado, es un riesgo. Usa variables de entorno configuradas en el servidor, o un gestor de secrets. Añade los archivos sensibles a tu .gitignore.
Prueba antes de desplegar
Con CI/CD puedes ejecutar pruebas automáticamente antes de que el código salga en directo. Si las pruebas fallan, el despliegue no sigue adelante. Así se detectan los bugs antes de que lleguen a producción. Incluso sin pruebas automatizadas, es sensato probar en local antes de hacer push.
Usa un entorno de pruebas (staging)
No despliegues directamente en producción. Ten un entorno de staging que se parezca lo máximo posible a producción. Despliega primero allí, prueba de forma manual o automatizada y solo después despliega en producción. Esto añade una capa de seguridad.
Considera los despliegues atómicos
Las configuraciones de despliegue avanzadas despliegan en un directorio nuevo y después cambian un enlace simbólico a la nueva versión. Si algo sale mal, puedes volver de inmediato a la versión anterior restaurando el enlace simbólico. La versión antigua se mantiene intacta. Herramientas como Deployer son compatibles con este patrón.
Ten una estrategia de rollback
Asegúrate de saber cómo volver a una versión anterior si algo sale mal. Con Git esto es técnicamente sencillo: puedes hacer un revert de un commit o un reset a un estado anterior. Pero practícalo antes de necesitarlo en plena crisis. Conoce los comandos y cómo funcionan.
Consideraciones específicas para WordPress y Git
WordPress requiere atención adicional en el despliegue con Git. El archivo wp-config.php contiene las credenciales de la base de datos y no debe estar en tu repositorio. Añádelo a .gitignore y gestiónalo por separado en el servidor. El directorio de uploads contiene los archivos multimedia que suben los usuarios y tampoco debe estar en Git. Usa .gitignore y gestiona los archivos multimedia por separado o a través de una CDN.
La propia base de datos contiene contenido y ajustes que no pasan por Git. Las migraciones de base de datos son más complejas que el despliegue de archivos. Considera una herramienta como WP Migrate o un flujo de trabajo con exportaciones de la base de datos.
Bedrock es un stack moderno de WordPress que funciona mejor con Git. Estructura WordPress como una dependencia y separa la configuración del código. Si te tomas en serio WordPress con Git, Bedrock merece que lo investigues.
Errores frecuentes y cómo evitarlos
Un error frecuente es desplegar sin probar. Funciona en local, así que seguro que funciona en producción, ¿no? No. Las diferencias entre entornos, las dependencias que faltan y las diferencias de configuración pueden causar problemas. Prueba siempre.
Hacer commit de credenciales es otro error con consecuencias graves. Aunque lo elimines más tarde, se queda en el historial de Git. Usa git-secrets o herramientas similares para evitar hacer commit de secrets por descuido.
No monitorizar tras el despliegue también es arriesgado. Despliegas y das por hecho que todo funciona. Pero comprueba de verdad que la web está funcionando y que las funciones críticas responden. Automatiza esto siempre que sea posible.
El despliegue con Git transforma la forma en que gestionas tus páginas web. La configuración inicial lleva tiempo, pero las ventajas en velocidad, fiabilidad y trazabilidad hacen que merezca con creces la pena. Empieza de forma sencilla con una configuración básica de git push y amplíala a CI/CD cuando tus necesidades crezcan.
Lista de comprobación y buenas prácticas del despliegue con Git
Un despliegue con git exitoso requiere un enfoque estructurado. Usa la lista de comprobación de abajo para asegurarte de que cada despliegue con git transcurre sin problemas.
- Comprueba que todos los cambios están confirmados con commit antes del despliegue con git
- Ejecuta las pruebas en local antes de iniciar un despliegue con git
- Usa ramas de funcionalidad (feature branches) y haz merge a main solo después de la revisión
- Configura el despliegue automático con git mediante pipelines de CI/CD
- Ten preparada una estrategia de rollback en cada despliegue con git
- Documenta cada despliegue con git en un changelog
| Método de despliegue con Git | Complejidad | Adecuado para |
|---|---|---|
| git pull manual | Baja | Proyectos pequeños |
| Hooks de Git (post-receive) | Media | Un solo servidor |
| CI/CD (GitHub Actions) | Media-alta | Equipos y proyectos profesionales |
| Kubernetes + GitOps | Alta | Grandes empresas y microservicios |
Tanto si alojas una página web sencilla en un VPS como si gestionas una aplicación compleja, el despliegue con git hace que la gestión de tu código sea clara y fiable. Combina el despliegue con git con un buen entorno de hosting para obtener los mejores resultados.
¿Cómo configurar el despliegue con git: pipelines de CI/CD?
El siguiente paso tras el despliegue con git manual es configurar un pipeline de CI/CD automatizado (integración continua y despliegue continuo). Con él, tu código se prueba y se despliega automáticamente en cuanto haces push de tus cambios a tu repositorio.
GitHub Actions para el despliegue
GitHub Actions es una opción popular para el despliegue automatizado. Defines workflows en archivos YAML que se ejecutan con cada push. Un workflow de despliegue típico incluye los siguientes pasos:
- Obtener el código del repositorio
- Instalar las dependencias (npm install, composer install)
- Ejecutar las pruebas (pruebas unitarias, pruebas de integración)
- Compilar los assets (compilar CSS y JavaScript)
- Desplegar en el servidor de producción mediante SSH o rsync
GitLab CI/CD como alternativa
GitLab ofrece una solución de CI/CD integrada que resulta especialmente potente. El pipeline se define en un archivo .gitlab-ci.yml en la raíz de tu repositorio. Además, GitLab es compatible con entornos, review apps y despliegue automático en clústeres de Kubernetes.
¿Cómo comparar estrategias de despliegue con git?
Existen varias estrategias de despliegue con git, cada una con sus propias ventajas e inconvenientes.
| Estrategia | Tiempo de inactividad | Complejidad | Rollback | Adecuado para |
|---|---|---|---|---|
| Despliegue directo | Corto | Baja | Git revert | Proyectos pequeños |
| Despliegue blue-green | Ninguno | Media | Inmediato (cambio de entorno) | Entornos de producción |
| Despliegue rolling | Ninguno | Alta | Gradual | Varios servidores |
| Despliegue canary | Ninguno | Alta | Rápido | Aplicaciones grandes |
El despliegue blue-green explicado
En el despliegue blue-green mantienes dos entornos de producción idénticos: «blue» (la versión actual) y «green» (la versión nueva). Despliegas el código nuevo en el entorno green, lo pruebas a fondo y después cambias el tráfico de blue a green. Si surgen problemas, vuelves atrás de inmediato.
Buenas prácticas para el despliegue con git
Para mantener tu proceso de despliegue con git fiable y seguro, sigue estas buenas prácticas:
- Usa ramas de funcionalidad: desarrolla las funciones nuevas en ramas aparte y haz merge a main solo cuando todo esté probado
- Automatiza las pruebas: no dejes que se despliegue nunca código que no haya superado todas las pruebas
- Configuración fuera del repositorio: guarda las contraseñas, las API keys y otros datos sensibles en variables de entorno, no en tu código
- Ejecuta las migraciones de base de datos por separado: lanza las migraciones antes de desplegar el código nuevo para evitar problemas de compatibilidad
- Monitorización tras el despliegue: configura una monitorización de la disponibilidad para detectar los problemas justo después del despliegue
- Documenta tu proceso de despliegue: asegúrate de que cualquier miembro del equipo pueda llevarlo a cabo, no solo el desarrollador principal
Con un proceso de despliegue con git bien montado ahorras horas por semana de trabajo manual y minimizas el riesgo de errores al poner en directo los cambios de tu página web.
Despliegue con git: cómo evitar los errores frecuentes
Al configurar el despliegue con git se repiten a menudo los mismos errores, que acaban dando problemas al poner los cambios en directo. Conoce estas trampas y evítalas.
El error más habitual es hacer commit de información sensible al repositorio. Las contraseñas, las API keys y los datos de las bases de datos no deben estar en tu código. Usa un archivo .gitignore para excluir los archivos de configuración y guarda los datos sensibles en variables de entorno. Si has hecho commit de secrets por descuido, no basta con eliminarlos en un commit nuevo: siguen estando en el historial de Git. Usa herramientas como git-filter-repo para reescribir el historial.
Otro error frecuente es desplegar directamente en producción sin usar un entorno de staging. Prueba siempre tus cambios primero en un entorno idéntico a producción. Así evitas que los bugs, los conflictos o los problemas de configuración se descubran solo en el servidor en directo. Automatiza este proceso configurando tu pipeline de CI/CD para que los cambios se desplieguen primero en staging.
No olvides tampoco hacer que tus scripts de despliegue sean idempotentes. Esto significa que el script produce el mismo resultado sin importar cuántas veces lo ejecutes. Si un despliegue falla a medias y lo vuelves a lanzar, no debería causar problemas. Usa comprobaciones condicionales y transacciones en tus scripts de migración para garantizarlo. Con unas buenas prácticas de migración y pruebas automatizadas, construyes un sistema de despliegue robusto que da confianza a tu equipo en cada release.
Despliegue con git: empieza con tu primer pipeline
Si todavía no tienes experiencia con el despliegue con git automatizado, empieza con una configuración sencilla que puedas ampliar poco a poco. La forma más simple de empezar es con un hook post-receive en tu servidor de producción. Es un script que se ejecuta automáticamente cuando haces push de tu código al servidor. El script obtiene el último código y reinicia el servidor web si hace falta.
Un paso más es configurar un workflow de GitHub Actions. Crea un archivo en tu repositorio en la ruta .github/workflows/deploy.yml. Define en él los pasos que deben ejecutarse con cada push a la rama main: obtener el código, ejecutar las pruebas y desplegar por SSH. GitHub ofrece muchos minutos gratis para repositorios públicos y privados, así que puedes empezar sin costes adicionales. Empieza de forma sencilla y ve añadiendo más pasos a medida que gane confianza. Un pipeline de CI/CD nunca está terminado: evoluciona junto con tu proyecto y se vuelve más fiable a medida que añades más pruebas y controles al proceso.
Despliegue con git: conclusión y próximos pasos
Con un sistema de despliegue con git bien montado llevas tu flujo de desarrollo a un nivel profesional. Las ventajas son evidentes: cada cambio es trazable, volver atrás es sencillo y colaborar con varios desarrolladores se hace sin conflictos. Empieza de forma sencilla con un workflow básico que despliegue automáticamente en tu servidor de producción con cada push a main. Ve añadiendo pasos poco a poco: pruebas automatizadas, linting, análisis de seguridad y notificaciones. Documenta tu proceso de despliegue para que cualquier miembro del equipo pueda ejecutarlo y entenderlo. Invierte en un entorno de staging para probar los cambios antes de que salgan en directo. Con estas piezas creas un proceso de despliegue fiable y repetible que te da confianza en cada release y minimiza el riesgo de errores humanos.
Buenas prácticas del despliegue con git para equipos
Al trabajar con despliegue con git en equipo hay buenas prácticas adicionales que hacen que el proceso fluya mejor. Usa branch protection rules para evitar que alguien pueda hacer push directamente a main sin revisión de código. Exige revisiones obligatorias de los pull requests para que al menos un miembro del equipo apruebe cada cambio antes de hacer merge. Usa mensajes de commit convencionales con un formato fijo para que el historial siga siendo legible y se puedan generar changelogs automáticamente. Implementa rollbacks automáticos que restauren la versión anterior si un despliegue falla o si la monitorización detecta que la versión nueva causa errores. Mantén tus ramas cortas: las ramas de funcionalidad que existen durante más de una semana resultan difíciles de fusionar y provocan conflictos. Con estas prácticas construyes un pipeline de despliegue robusto que cuenta con la confianza de todo el equipo.
