- Los Git Hooks son scripts que se ejecutan automáticamente ante eventos como commits o pushes para validar el código.
- Se distinguen hooks de cliente, para rapidez local, y hooks de servidor, para reglas obligatorias de equipo.
- La gestión profesional de hooks requiere herramientas como Husky o la configuración de core.hooksPath para compartirlos en el equipo.
- Su integración con flujos de CI/CD permite despliegues web automatizados y una reducción drástica de errores manuales.
Imagina que pudieras tener un asistente personal que revisara cada línea de tu código, comprobara que los mensajes de commit no son un desastre y lanzara las pruebas unitarias justo antes de que subas los cambios al servidor, todo sin que tengas que mover un dedo. Pues bien, eso es exactamente lo que hacen los Git Hooks, esos pequeños scripts que se quedan al acecho en tu repositorio para automatizar tareas tediosas y evitar que metas la pata en el momento menos oportuno.
Ya sea que trabajes solo en un proyecto personal o que formes parte de un equipo grande, integrar estas automatizaciones en Git for Windows es un salto de calidad brutal. No se trata solo de ahorrar tiempo, sino de estandarizar el flujo de trabajo para que el código sea limpio, consistente y, sobre todo, libre de errores evitables antes de que lleguen a la rama principal.
¿Qué demonios son los Git Hooks y cómo funcionan?
En esencia, los hooks son guiones personalizados que Git dispara automáticamente cuando ocurre un evento específico en el ciclo de vida del desarrollo. Piensa en ellos como disparadores de eventos: cuando haces un commit, un push o un merge, Git mira si hay un script correspondiente en la carpeta de configuración y, si lo hay, lo ejecuta. Si el script devuelve un error (un código de salida 1), Git bloquea la operación, obligándote a corregir el problema antes de seguir.
Estos scripts se guardan en una zona oculta de tu proyecto, concretamente en el directorio .git/hooks. Al crear un repositorio, Git ya te deja ahí unas cuantas plantillas con la extensión .sample para que no empieces de cero. Solo tienes que renombrarlas, quitarles esa extensión y añadirles tu propia lógica, ya sea usando Bash, Python o Ruby, siempre que el sistema pueda ejecutarlos.
Tipos de ganchos: ¿Cuál elegir según el momento?
Para no liarnos, es fundamental distinguir entre los hooks que viven en tu ordenador (lado del cliente) y los que residen en el servidor remoto.
Hooks del lado del cliente
Estos son los más comunes para el día a día del desarrollador, ya que permiten detectar fallos al instante sin esperar a que el servidor de CI/CD nos regañe:
- pre-commit: Es el guardián del código. Se lanza antes de que se cree el commit. Es ideal para ejecutar linters o formateadores como Prettier o ESLint, asegurando que nadie suba código con indentaciones raras o errores de sintaxis.
- prepare-commit-msg: Útil para rellenar automáticamente el mensaje del commit, añadiendo, por ejemplo, el número de la tarea de Jira o el nombre de la rama.
- commit-msg: Este se encarga de que el mensaje sea descriptivo. Puedes forzar que sigan la metodología de Conventional Commits (usando prefijos como feat: o fix:), evitando los clásicos mensajes tipo «cambios varios» que no dicen nada.
- post-commit: Se ejecuta tras confirmar los cambios. Sirve para lanzar notificaciones o actualizar documentación local.
- pre-push: Es la última línea de defensa. Ejecuta pruebas más exhaustivas antes de enviar el código al remoto, evitando que rompas la build de tus compañeros.
- post-checkout y post-merge: Ideales para actualizar submódulos o limpiar cachés del entorno cada vez que cambias de rama o fusionas código.
Hooks del lado del servidor
Estos se configuran en el repositorio «bare» del servidor y son obligatorios para todo el equipo, ya que no se pueden saltar con el comando –no-verify:
- pre-receive: Valida que el push cumpla reglas estrictas antes de aceptarlo en el servidor.
- update: Similar al anterior, pero se ejecuta una vez por cada rama que se esté actualizando.
- post-receive: El rey de la automatización. Se usa para desplegar el código automáticamente en el servidor web o enviar alertas a Slack informando que hay cambios nuevos.
Guía paso a paso para montar tu primer Hook
Si quieres empezar ya mismo en Windows, el proceso es bastante sencillo. Primero, navega hasta la carpeta .git/hooks de tu proyecto. Si quieres activar un pre-commit, crea un archivo llamado exactamente así, sin ninguna extensión. Para que Git lo reconozca, debes asegurarte de que sea ejecutable; en sistemas basados en Unix o usando Git Bash en Windows, el comando es chmod +x .git/hooks/pre-commit.
Una vez creado, abre el archivo con tu editor favorito y añade el shebang al principio (por ejemplo, #!/bin/bash) para decirle al sistema qué intérprete usar. A continuación, escribe la lógica. Por ejemplo, si usas PHP, podrías integrar PHP CodeSniffer para que el commit falle si el estilo no es el correcto. Recuerda que si el script termina con exit 0, la operación sigue adelante, pero si termina con exit 1, Git detendrá el proceso inmediatamente.
Integración con CI/CD y despliegue web
Aunque los hooks son potentes, no deben sustituir a una plataforma de Integración Continua y Entrega Continua (CI/CD) como Jenkins, GitHub Actions o GitLab CI, sino complementarla. La estrategia ideal es un enfoque híbrido: usa hooks locales para validaciones rápidas (linting, tests unitarios simples) y deja que la plataforma de CI/CD se encargue de las pruebas pesadas, la compilación y el despliegue en entornos de staging y producción.
Para automatizar un despliegue web básico, puedes configurar un hook post-receive en tu servidor. El script podría ejecutar un comando git checkout -f hacia la carpeta donde reside tu web y luego reiniciar el servidor Nginx o Apache. Esto reduce los errores manuales en un porcentaje altísimo y permite que las actualizaciones lleguen a producción en cuestión de minutos.
Trucos para no volverse loco con los Hooks
Hay un problema: la carpeta .git no se sube al repositorio, por lo que los hooks son locales y cada desarrollador tendría que configurarlos a mano. Para evitar este caos, existen dos soluciones principales. La primera es crear una carpeta propia en el proyecto (como .githooks), subirla al repo y ejecutar el comando git config core.hooksPath .githooks para decirle a Git que busque los scripts allí.
La segunda opción, y quizás la más profesional, es usar herramientas como Husky (para Node.js) o el framework pre-commit. Estas herramientas permiten definir los hooks en un archivo YAML, facilitando que todo el equipo tenga la misma configuración de forma automática al instalar las dependencias del proyecto.
Eso sí, ten cuidado con no pasarte de la raya. Si creas hooks demasiado pesados que tarden minutos en ejecutarse, los desarrolladores acabarán odiándolos y empezarán a usar –no-verify para saltárselos. Mantén los scripts ligeros, documenta bien qué hace cada uno en el README y prioriza la velocidad para que la herramienta sea una ayuda y no un estorbo.
Ventajas, riesgos y mejores prácticas
Implementar esta metodología aporta beneficios claros: se reduce la cantidad de bugs que llegan al servidor, el código es mucho más homogéneo y el equipo gasta menos tiempo en revisiones manuales superficiales. Sin embargo, existe el riesgo de generar una dependencia excesiva del entorno local o de introducir scripts inseguros que expongan credenciales si no se gestionan bien mediante variables de entorno.
Para evitar problemas, lo más inteligente es modularizar los pipelines, separando la compilación, las pruebas y el despliegue. Implementar estrategias de despliegue blue-green junto con hooks de servidor permite cambiar el tráfico de manera fluida y volver atrás rápidamente si algo falla, minimizando el tiempo de inactividad.
Tener el control total de los eventos de Git mediante scripts personalizados permite que el flujo de desarrollo sea mucho más fluido y seguro, eliminando el factor del error humano en tareas repetitivas. Al combinar la rapidez de los hooks locales con la robustez de un servidor de CI/CD y herramientas de gestión como Husky, cualquier equipo puede garantizar que solo el código que cumple con los estándares más estrictos llegue a producción, optimizando así la productividad y la calidad final del software.