Deja que git hooks se ocupe de automatizar tareas, comprobar errores en commits, y mucho más de manera automática al trabajar con un repositorio en git

Los git hooks son una serie de scripts que se crean de manera automática al crear un repositorio git y que se «disparan» de manera automática ante ciertos eventos al trabajar con git. Por ejemplo al crear un commit, al recibir un push, etc.
Los podemos activar y personalizar a nuestras necesidades y utilizarlos para prevenir errores como enviar un commit a una rama equivocada, enviar una notificación antes de realizar un commit, etc.
Vamos a echar un vistazo a esos git hooks. Como siempre digo, no soy experto y por eso siempre remito a la documentación oficial. Aquí veremos algún ejemplo de uso de estos git hooks.
Te recomiendo abrir una terminal en tu equipo e ir siguiendo los pasos. Vamos a hacer una carpeta llamada prueba, entramos en ella y la inicializamos como repositorio git. Todo esto así:
mkdir prueba
cd prueba
git init
Cada vez que creas un nuevo repositorio de git en tu equipo como lo que hemos hecho en estos pasos, se creará una carpeta oculta llamada .git y dentro de esta otras carpetas y hay una llamada hooks y dentro de esa carpeta varios scripts listos para poder utilizarlos, veamos cómo.
Cabe recordar que esta carpeta .git no se subirá al repositorio git remoto. Por lo que estarán en tu equipo, pero no formarán del repositorio upstream.
Dentro de nuestra carpeta prueba, entramos en la carpeta .git/hooks y veremos que existen unos archivos similares a estos:
applypatch-msg.sample
commit-msg.sample
fsmonitor-watchman.sample
post-update.sample
pre-applypatch.sample
pre-commit.sample
pre-merge-commit.sample
pre-push.sample
pre-rebase.sample
pre-receive.sample
prepare-commit-msg.sample
push-to-checkout.sample
update.sample
- pre-commit → se ejecuta hantes de realizar un commit
- prepare-commit-msg → se ejecuta antes de escribir un mensaje de commit
- commit-msg → se ejecuta después de escribir un mensaje de commit
- post-commit → se ejecuta después de realizar un commit
- pre-rebase → antes de realizar un rebase
- post-checkout → después de realizar un checkout
- post-merge → después de realizar un merge
- pre-receive → antes de recibir un push
- post-receive → después de recibir un push
- update → antes de recibir un push, se ejecuta una vez por rama
Pero hay alguno más. Estos scripts son unos ejemplos para utilizarlos como git hooks, sus nombres son bastante indicativos de cuando se ejecuta cada script. Puedes ver el contenido de código de uno de ellos.
Algunos están pensados para ser ejecutados desde el lado del cliente y otros son específicos para el lado del servidor donde esté ubicado el repositorio git.
Para utilizarlos, basta con eliminarles la extensión .sample y darle derechos de ejecución. Los códigos de los scripts son una guía que podemos utilizar. Pero podemos modificarlos a nuestras necesidades o utilizar otro lenguaje de programación como Python en vez de bash si lo preferimos, para adaptar los scripts a nuestras necesidades.
Vamos a habilitar el script commit-msg. Para ello, como he dicho, lo renombramos y le hacemos ejecutable:
mv commit-msg.sample commit-msg
chmod +x commit-msg
Editamos el archivo y podemos por ejemplo pegar este pequeño script en Bash:
#!/bin/sh
# Comprueba que el mensaje del commit es mayor de 4 caracteres y menor de 30
commit=$(head -n1 $1)
if [[ $(echo $commit | wc -c) -lt 5 || $(echo $commit | wc -c) -gt 30 ]];then
echo -e "El texto del commit debe ser mayor de 5 caracteres y menor de 30.\nPor favor vuelve a escribir un nuevo commit"
exit 1
fi
Con este script, «forzamos» a quien quiera crear un commit a que el comentario que introduzca sea mayor de 4 caracteres y menos de 30. De no cumplir eso, le mostrará el texto por pantalla y no se aceptará el commit.
Al igual que este script, también podemos crear otro, para comprobar que los commits cumplen unas normas, por ejemplo que empiecen de una manera determinada, o lo que necesitemos.
Otras tareas que podemos habilitar con otros scripts es enviar un correo de notificación a los responsables del repositorio de que se ha recibido un nuevo push.
O quizás al recibir un nuevo aporte a nuestro repositorio ejecutar un determinado script que refleje esos cambios en una página web, etc…
Aquí depende del uso que se les quiera dar para cada caso determinado. Por la red hay varios ejemplos de uso de diferentes casos para que les eches un vistazo, por si alguno se puede adaptar a tus necesidades.
La verdad es que creo que los git hooks no son muy conocidos para el partido que se les puede sacar.
Dejo por aquí una librería en php para integrar git hooks con herramientas de validación de código de forma fácil, por si a alguien le sirve:
https://github.com/Wtyd/githooks
Gracias por el aporte!!! y por la visita para comentar!! 😉
Saludos…