El uso de Git Hooks: Pre-Push#

En esta ocasión quiero compartir contigo un tema que ha resultado clave en mis últimos proyectos: el uso del git hook pre-push juno a draft pull request en GitHub, si te ha pasado eso de quedarte esperando a que la CI falle para descubrir un error de principiante, este artículo te va a interesar.

Mi objetivo es que, al terminar de leer, tengas las herramientas y la motivación necesarias para implementar (o al menos probar) esta estrategia en tus propios repositorios. ¡Vamos a ello!

Un Desafío Constante: Velocidad vs. Calidad#

En el desarrollo de software, siempre existe la tensión entre entregar rápido y mantener un nivel alto de calidad. Por un lado, los equipos se esfuerzan por cumplir deadlines y sacar nuevas funcionalidades. Por otro lado, una mínima negligencia puede derivar en bugs o “ciclos de ida y vuelta” interminables:

  1. Subes tu código (creyendo que está bien).

  2. Esperas a la CI/CD.

  3. Descubres un error trivial.

  4. Corriges y vuelves a esperar otra ronda.

La pregunta es: ¿Existe una forma de atrapar esos errores antes de que lleguen al servidor y manteniendo la fluidez de trabajo?

La respuesta corta es sí, y uno de mis enfoques favoritos combina hooks locales y ramas de borrador.

¿Qué es Pre-Push Hook?#

Un Pre-Push es un script que se ejecuta automáticamente en tu entorno local antes de que el código se “empuje” (push) al repositorio remoto. Puede ser tan sencillo como correr un linter y un par de tests, o tan complejo como analizar vulnerabilidades. Si alguno de los checks falla, el hook puede detener el push y advertirte para que corrijas el problema localmente.

¿Por Qué Ayuda?#

  • Retroalimentación Instantánea: Evitas el ciclo de “subir y esperar” solo para descubrir un error básico.

  • Menos Gasto en CI/CD: Cada ciclo fallido en la nube consume tiempo y recursos, así que si lo evitas localmente, optimizas tu proceso.

  • Fomenta la Calidad: Te obliga (de la mejor manera) a asegurarte de que tu código cumple ciertos estándares antes de compartirlo con el equipo.

Ejemplo rápido: un script pre-push podría ejecutar:

npm run lint && npm run test

o podría ejecutar:

php -d vendor/bin/psalm --config=psalm.xml --no-cache && \
php -d vendor/bin/phpunit -c phpunit.xml --coverage-html

Si falla alguno, se cancela el push. De esta forma, los pequeños despistes se solucionan al instante, sin atorar a todo el equipo.

Dudas Comunes Sobre el Pre-Push Hook#

1. “¿No es Redundante si ya uso GitHub Actions?”#

La CI/CD es genial, pero se activa en remoto. Cada intento fallido en la nube consume minutos valiosos y puede generar cuellos de botella. Detectarlo antes de subir significa ganar tiempo, productividad y enfoque.

2. “¿Bloquea Mi Flujo de Trabajo?”#

Un pre-push hook está pensado para agilizar, no bloquear. Es cierto que, si falla, deberás corregir antes de empujar el código, pero eso contribuye a una mejora continua. Y si surge una emergencia, siempre existe la opción de:

git push --no-verify

3. “¿Qué Pasa si Quiero Subir Código Incompleto?”#

Aquí entra en juego la segunda parte de nuestro método: ramas de borrador. Veamos.

Draft pull requests:#

!El complemento Perfecto¡#

Las ramas de borrador (o draft pull requests) son ideales para esos momentos en los que necesitas compartir trabajo en progreso sin todas las restricciones. Básicamente, GitHub te permite crear una Pull Request en modo “borrador”. Así, no se dispara la CI/CD al completo y queda claro para todos que tu código está en construcción.

  1. Creas la rama: `git checkout -b feature/maravillosa-funcionalidad`

  2. Subes tus cambios: `git push` Si el hook no te deja por errores básicos y aun así necesitas mostrar algo, tienes dos caminos:

    1. Revisar y corregir (lo recomendable).

    2. Usar `--no-verify` de forma puntual.

  3. Abres una Pull Request “Draft”: Se indicará que es un borrador y que no está listo para revisión formal.

  4. Iteras con tu equipo: Ellos pueden ver tu código, hacer comentarios, incluso contribuir directamente si lo permiten las políticas del repositorio. La clave es que no estás forzando validaciones exhaustivas en un momento prematuro, pero sí mantienes la práctica del pre-push en la rama principal o en las PRs finales que ya vayan a integrarse.

Cómo Implementar un Hook Local Básico#

Para quienes quieran un ejemplo sencillo en un repositorio de Node.js:

  1. Crea o edita el archivo `.git/hooks/pre-push`:

bash
   #!/usr/bin/env bash
   echo "Checking code quality..."

   npm run lint
   if [ $? -ne 0 ]; then
     echo "The linter found problems. Please correct before pushing."
     exit 1
   fi

   npm run test
   if [ $? -ne 0 ]; then
     echo "The tests failed. Please review the report before continuing."
     exit 1
   fi

   echo "All OK! Uploading changes..."
   exit 0

  1. Asegúrate de que sea ejecutable:

chmod +x .git/hooks/pre-push

  1. Si alguna vez necesitas saltártelo (con responsabilidad):

git push --no-verify

Obviamente, puedes personalizarlo según tus necesidades (formateo, seguridad, métricas de cobertura, emojis, etc.).

La Clave: Flexibilidad con Buenas Prácticas#

En realidad, no se trata de imponer un sistema rígido, sino de combinar herramientas que, bien utilizadas, hacen tu vida más fácil:

  • El pre-push hook te evita sorpresas en la CI/CD y promueve una cultura de código limpio.

  • Las ramas de borrador te dan la libertad de mostrar avances tempranos, incluso si no has finalizado o refinado todo.

Con este tándem, es posible lograr un flujo de trabajo donde todos (tú, tu equipo y la CI/CD) trabajen con el mismo objetivo: construir software que funcione y sea mantenible.

Beneficios Reales para El Equipo#

  1. Menos Fricción en Revisiones: Los errores triviales (falta de formateo, tests unitarios que fallan) se corrigen localmente.

  2. Ahorro de Tiempo: Fewer "red pipelines" en la nube implica menos esperas, menos frustración y un ciclo de desarrollo más fluido.

  3. Responsabilidad Compartida: El hook crea un hábito de comprobación de calidad automática, sin que nadie deba “recordar” ejecutarlo manualmente.

  4. Visibilidad de Progreso: Las ramas de borrador aportan transparencia sobre lo que se está haciendo, sin entorpecer la integración formal.

¿Te Animas a Probarlo?#

Si estás buscando un enfoque práctico para elevar la calidad de tu código sin sacrificar velocidad, te animo a implementar estas ideas en tu repositorio. Empieza con un pre-push hook sencillo y habilita draft PRs para esos trabajos incompletos que necesitas compartir.

¡Te aseguro que, una vez veas la reducción de fallas en la CI/CD y la fluidez en la colaboración, no querrás volver atrás!

¿Te Gustó Este Contenido?#

Si te ha resultado útil o te ha dejado con más preguntas que respuestas, te invito a suscribirte a mi newsletter. Cada semana comparto tips, reflexiones y experiencias personales sobre desarrollo backend, mejora continua y herramientas que facilitan la vida a los equipos de software.

¡Gracias por leerme! Espero verte pronto en los comentarios o en la próxima edición.