Git no solo sirve para guardar versiones de código: también puede convertirse en un aliado para automatizar tareas repetitivas en tu flujo de trabajo. Una de las formas más potentes de hacerlo es mediante Git Hooks, pequeños scripts que se ejecutan en momentos concretos del ciclo de vida de Git.
Si ya dominas conceptos como crear commits correctamente, revisar el estado del repositorio o ignorar archivos con .gitignore, los hooks son el siguiente paso natural para profesionalizar tu trabajo con Git.
Qué son los git hooks
Los Git Hooks son scripts locales o del servidor que Git ejecuta automáticamente antes o después de eventos como un commit, un push o un merge. Su objetivo es simple: automatizar validaciones y acciones sin que tengas que recordarlas manualmente cada vez.
Por ejemplo, puedes usar un hook para comprobar que el código está formateado, ejecutar tests, impedir commits con mensajes vacíos o lanzar tareas de despliegue cuando se suben cambios. En el día a día, esto reduce errores, ahorra tiempo y ayuda a mantener estándares de calidad consistentes.
Hooks locales y hooks del servidor
Los hooks locales se ejecutan en tu máquina, dentro del repositorio. Son ideales para validar antes de commit o push. Los hooks del servidor, en cambio, se ejecutan del lado remoto y suelen usarse para políticas más estrictas, aunque dependen de la infraestructura de la plataforma.
En este artículo nos centraremos sobre todo en los hooks locales, porque son los más accesibles y fáciles de aplicar en casi cualquier proyecto.
Dónde se guardan y cómo funcionan
Git almacena sus hooks dentro de la carpeta .git/hooks del repositorio. Al crear un repositorio, encontrarás varios archivos de ejemplo con extensión .sample. Esos ejemplos sirven como referencia para escribir tus propios scripts.
Un detalle importante: Git no activa por defecto todos los hooks de ejemplo. Para usarlos, normalmente debes crear un archivo ejecutable sin la extensión .sample y colocar ahí tu lógica.
# Ejemplo: estructura básica de un hook local
repo/
└── .git/
└── hooks/
├── pre-commit
├── commit-msg
└── pre-push
# Git ejecutará estos archivos si tienen permisos de ejecución
# y contienen código válido para el intérprete indicado en la primera línea
La primera línea del script suele ser un shebang, como #!/bin/sh o #!/bin/bash, para indicar con qué intérprete debe ejecutarse. Después, puedes añadir las comprobaciones o acciones que necesites.
Hooks más útiles para automatizar tareas
pre-commit: validar antes de crear el commit
Este es probablemente el hook más popular. Se ejecuta antes de que Git confirme el commit y es perfecto para tareas como:
• lanzar un formateador de código
• ejecutar linters
• detectar archivos sensibles o secretos
• impedir commits si hay errores evidentes
Su gran ventaja es que evita que código defectuoso llegue al historial. Si tu proyecto ya sigue buenas prácticas en los mensajes, como las que explicamos en este artículo sobre mensajes de commit, el hook pre-commit puede complementar esa disciplina con validaciones automáticas.
commit-msg: controlar la calidad del mensaje
Este hook se ejecuta después de escribir el mensaje del commit, pero antes de que Git lo registre definitivamente. Se usa mucho para verificar formatos específicos, como convenciones tipo Conventional Commits o reglas internas del equipo.
Por ejemplo, podrías bloquear mensajes vacíos o exigir que el texto empiece por un prefijo concreto. Esto ayuda a mantener un historial más legible, especialmente en equipos grandes.
pre-push: revisar antes de subir cambios
Este hook se ejecuta justo antes de un git push. Es útil cuando quieres correr pruebas rápidas, comprobar cobertura mínima o evitar que se suban cambios que rompan el proyecto.
Es una capa de seguridad interesante porque actúa justo antes de publicar el trabajo en el repositorio remoto. Si todavía no tienes claro el mecanismo con el que envías cambios al servidor, conviene repasar cómo funciona git push.
post-commit y post-checkout: tareas informativas
Los hooks post-commit y post-checkout no bloquean acciones; se usan para automatizaciones complementarias. Por ejemplo, puedes mostrar recordatorios, imprimir información útil o sincronizar alguna herramienta externa.
Son menos restrictivos que pre-commit o pre-push, pero muy útiles para mejorar la experiencia del desarrollador sin interrumpir el flujo.
Ejemplo práctico de pre-commit
Veamos un ejemplo sencillo de hook pre-commit que verifica si hay archivos JavaScript con errores de formato mediante un comando ficticio de lint. La idea real es la misma aunque adaptes la herramienta a tu stack.
#!/bin/sh
# pre-commit: valida el código antes de aceptar el commit
echo "Ejecutando validaciones previas al commit..."
# Ejemplo de comprobación de estilo o lint
npm run lint
if [ $? -ne 0 ]; then
echo "Error: el lint ha fallado. Corrige los problemas antes de commitear."
exit 1
fi
echo "Validación superada."
exit 0
Si el comando devuelve error, el commit se cancela. Ese comportamiento es justo lo que hace valiosos a los hooks: actúan como un guardián automático para tu flujo de desarrollo.
Recuerda que este ejemplo debe adaptarse a tu entorno real. En un proyecto Python podrías usar pytest o ruff; en uno frontend, formateadores y linters; en un backend, pruebas unitarias o chequeos de configuración.
Buenas prácticas para usarlos sin fricción
No conviertas el hook en una barrera excesiva
Si un hook tarda demasiado, el equipo tenderá a buscar formas de saltárselo. La clave está en automatizar tareas rápidas y de alto valor. Para validaciones pesadas, suele ser mejor delegarlas a CI/CD.
Una buena estrategia es reservar los hooks locales para checks inmediatos y dejar para la automatización del pipeline pruebas más costosas o despliegues complejos.
Mantén la lógica simple y versionable
La carpeta .git/hooks no se comparte automáticamente con el resto del equipo, así que conviene almacenar los scripts en un directorio del proyecto y enlazarlos desde la configuración del repositorio. De ese modo, puedes versionarlos y mantenerlos consistentes entre desarrolladores.
Este enfoque también facilita el mantenimiento y evita que cada persona tenga una versión distinta del hook.
Documenta qué hace cada hook
Cuando una automatización bloquea un commit o un push, el mensaje de error debe ser claro y útil. Explica qué falló y cómo corregirlo. Eso reduce frustración y mejora la adopción del sistema.
Una mala experiencia con los hooks puede hacer que el equipo los vea como un obstáculo. Una buena experiencia los convierte en una red de seguridad invisible.
Relación con otros flujos de trabajo de git
Los Git Hooks encajan especialmente bien en equipos que ya trabajan con ramas, revisiones y despliegues frecuentes. Si utilizas ramas para separar funcionalidades, como explicamos en qué son las ramas en Git, los hooks ayudan a mantener un estándar mínimo antes de integrar cambios.
También son útiles en flujos donde hay varios pasos de validación antes de publicar, algo muy común cuando se compara Git Flow vs GitHub Flow. En ambos casos, automatizar comprobaciones locales reduce problemas en la integración posterior.
Errores comunes al empezar
Un error frecuente es intentar usar hooks para todo. No hace falta automatizar cada paso del desarrollo. Empieza por uno o dos procesos repetidos, como lint, tests rápidos o validación de mensajes, y amplía según la necesidad real del equipo.
Otro fallo habitual es olvidar los permisos de ejecución. Si el script no es ejecutable, Git no lo lanzará. También es importante probar el hook en distintos sistemas si trabajas con Linux, macOS y Windows, porque algunas rutas o intérpretes pueden variar.
Por último, no confíes en los hooks como única capa de control. Son una herramienta local valiosa, pero deben complementar, no sustituir, las revisiones de código y la automatización centralizada.
Conclusión
Automatizar tareas con Git Hooks es una de esas mejoras pequeñas que marcan una gran diferencia. Te permiten validar código, reforzar estándares y ahorrar tiempo en tareas repetitivas sin añadir pasos manuales a cada commit o push.
Si ya trabajas con Git de forma habitual, los hooks son una evolución natural de tu flujo. Empieza por un pre-commit sencillo, mide su impacto y luego añade otras comprobaciones según crezca tu proyecto. La meta no es imponer más reglas, sino construir un proceso más fiable y cómodo.
Fuentes y lecturas recomendadas
Documentación oficial de Git sobre hooks
Guía de Git en la documentación de GitHub
Explicación práctica de Git Hooks en Atlassian
Deja una respuesta