Al igual que muchos otros Sistemas de Control de Versiones, Git tiene una manera de activar scripts personalizados cuando ocurren ciertas acciones importantes. Hay dos grupos de estos ganchos: del lado del cliente y del lado del servidor. Los ganchos del lado del cliente son activados por operaciones como commits y fusiones, mientras que los ganchos del lado del servidor se ejecutan en operaciones de red como la recepción de commits enviados. Puede utilizar estos ganchos para todo tipo de razones.
Todos los ganchos se almacenan en el subdirectorio hooks del directorio Git. En la mayoría de los proyectos, ese es .git/hooks. Cuando inicializa un nuevo repositorio con git init, Git pobla el directorio de ganchos con un montón de scripts de ejemplo, muchos de los cuales son útiles por sí mismos; pero también documentan los valores de entrada de cada script. Todos los ejemplos están escritos como scripts de shell, con algo de Perl, pero cualquier script ejecutable con el nombre adecuado funcionará bien: puede escribirlos en Ruby o Python o cualquier otro lenguaje con el que esté familiarizado. Si desea utilizar los scripts de gancho incluidos, tendrá que renombrarlos; sus nombres de archivo terminan todos con .sample.
Para habilitar un script de gancho, coloque un archivo en el subdirectorio hooks de su directorio .git que tenga el nombre adecuado (sin ninguna extensión) y sea ejecutable. A partir de ese momento, debería ser llamado. Cubriremos la mayoría de los nombres de archivos de ganchos importantes aquí.
Hay muchos ganchos del lado del cliente. Esta sección los divide en ganchos de flujo de trabajo de commit, scripts de flujo de trabajo de correo electrónico y todo lo demás.
|
Note
|
Es importante tener en cuenta que los ganchos del lado del cliente no se copian cuando clona un repositorio. Si su intención con estos scripts es hacer cumplir una política, probablemente querrá hacerlo del lado del servidor; vea el ejemplo en ch08-customizing-git.asc. |
Los primeros cuatro ganchos tienen que ver con el proceso de commit.
El gancho pre-commit se ejecuta primero, antes de que incluso escriba un mensaje de commit. Se utiliza para inspeccionar la instantánea que está a punto de ser commiteada, para ver si ha olvidado algo, para asegurarse de que las pruebas se ejecuten, o para examinar lo que necesite inspeccionar en el código. Salir con un código distinto de cero de este gancho aborta el commit, aunque puede omitirlo con git commit --no-verify. Puede hacer cosas como verificar el estilo del código (ejecutar lint o algo equivalente), verificar espacios en blanco al final (el gancho predeterminado hace exactamente esto), o verificar la documentación adecuada en nuevos métodos.
El gancho prepare-commit-msg se ejecuta antes de que se active el editor de mensajes de commit, pero después de que se haya creado el mensaje predeterminado. Le permite editar el mensaje predeterminado antes de que el autor del commit lo vea. Este gancho toma algunos parámetros: la ruta al archivo que contiene el mensaje de commit hasta ahora, el tipo de commit y el SHA-1 del commit si se trata de un commit modificado. Este gancho generalmente no es útil para commits normales; más bien, es bueno para commits donde el mensaje predeterminado es generado automáticamente, como mensajes de commit plantillados, commits de fusión, commits aplastados y commits modificados. Puede usarlo en conjunto con una plantilla de commit para insertar información de manera programática.
El gancho commit-msg toma un parámetro, que nuevamente es la ruta a un archivo temporal que contiene el mensaje de commit escrito por el desarrollador. Si este script sale con un código distinto de cero, Git aborta el proceso de commit, por lo que puede usarlo para validar el estado de su proyecto o el mensaje de commit antes de permitir que un commit se realice. En la última sección de este capítulo, demostraremos el uso de este gancho para verificar que su mensaje de commit cumpla con un patrón requerido.
Después de que se completa todo el proceso de commit, se ejecuta el gancho post-commit. No toma ningún parámetro, pero puede obtener fácilmente el último commit ejecutando git log -1 HEAD. Generalmente, este script se utiliza para notificación o algo similar.
Puede configurar tres ganchos del lado del cliente para un flujo de trabajo basado en correo electrónico. Todos son invocados por el comando git am, por lo que si no está utilizando ese comando en su flujo de trabajo, puede saltar de manera segura a la siguiente sección. Si está tomando parches por correo electrónico preparados por git format-patch, entonces algunos de estos pueden serle útiles.
El primer gancho que se ejecuta es applypatch-msg. Toma un solo argumento: el nombre del archivo temporal que contiene el mensaje de commit propuesto. Git aborta el parche si este script sale con un código distinto de cero. Puede usar esto para asegurarse de que un mensaje de commit esté correctamente formado, o para normalizar el mensaje haciendo que el script lo edite en su lugar.
El siguiente gancho que se ejecuta al aplicar parches a través de git am es pre-applypatch. Algo confusamente, se ejecuta después de que se aplica el parche pero antes de que se haga un commit, por lo que puede usarlo para inspeccionar la instantánea antes de hacer el commit. Puede ejecutar pruebas o inspeccionar de otra manera el árbol de trabajo con este script. Si falta algo o las pruebas no pasan, salir con un código distinto de cero aborta el script git am sin commitear el parche.
El último gancho que se ejecuta durante una operación git am es post-applypatch, que se ejecuta después de que se hace el commit. Puede usarlo para notificar a un grupo o al autor del parche que ha incorporado que lo ha hecho. No puede detener el proceso de parcheo con este script.
El gancho pre-rebase se ejecuta antes de que rebasee nada y puede detener el proceso saliendo con un código distinto de cero. Puede usar este gancho para no permitir el rebase de cualquier commit que ya haya sido enviado. El gancho de ejemplo pre-rebase que instala Git hace esto, aunque hace algunas suposiciones que pueden no coincidir con su flujo de trabajo.
El gancho post-rewrite es ejecutado por comandos que reemplazan commits, como git commit --amend y git rebase (aunque no por git filter-branch). Su único argumento es qué comando desencadenó la reescritura, y recibe una lista de reescrituras en stdin. Este gancho tiene muchos de los mismos usos que los ganchos post-checkout y post-merge.
Después de ejecutar un git checkout exitoso, se ejecuta el gancho post-checkout; puede usarlo para configurar su directorio de trabajo correctamente para su entorno de proyecto. Esto puede significar mover archivos binarios grandes que no desea controlar con el código fuente, generar automáticamente documentación, o algo similar.
El gancho post-merge se ejecuta después de un comando merge exitoso. Puede usarlo para restaurar datos en el árbol de trabajo que Git no puede rastrear, como datos de permisos. Este gancho también puede validar la presencia de archivos externos al control de Git que pueda querer copiar cuando el árbol de trabajo cambie.
El gancho pre-push se ejecuta durante git push, después de que se hayan actualizado las referencias remotas pero antes de que se hayan transferido objetos. Recibe el nombre y la ubicación del repositorio remoto como parámetros, y una lista de referencias a actualizar a través de stdin. Puede usarlo para validar un conjunto de actualizaciones de referencias antes de que ocurra un push (un código de salida distinto de cero abortará el push).
Git ocasionalmente hace recolección de basura como parte de su operación normal, invocando git gc --auto. El gancho pre-auto-gc se invoca justo antes de que ocurra la recolección de basura, y puede usarse para notificarle que esto está sucediendo, o para abortar la recolección si ahora no es un buen momento.
Además de los ganchos del lado del cliente, puede utilizar un par de ganchos importantes del lado del servidor como administrador del sistema para hacer cumplir casi cualquier tipo de política para su proyecto. Estos scripts se ejecutan antes y después de los envíos al servidor. Los ganchos previos pueden salir con un código distinto de cero en cualquier momento para rechazar el envío, así como imprimir un mensaje de error de vuelta al cliente; puede configurar una política de envío que sea tan compleja como desee.
El primer script que se ejecuta al manejar un envío desde un cliente es pre-receive. Toma una lista de referencias que se están enviando desde stdin; si sale con un código distinto de cero, ninguna de ellas es aceptada. Puede usar este gancho para hacer cosas como asegurarse de que ninguna de las referencias actualizadas sean no-fast-forward, o para hacer control de acceso para todas las referencias y archivos que están modificando con el envío.
El script update es muy similar al script pre-receive, excepto que se ejecuta una vez por cada rama que el que envía está tratando de actualizar. Si el que envía está tratando de enviar a múltiples ramas, pre-receive se ejecuta solo una vez, mientras que update se ejecuta una vez por cada rama a la que están enviando. En lugar de leer desde stdin, este script toma tres argumentos: el nombre de la referencia (rama), el SHA-1 al que apuntaba esa referencia antes del envío, y el SHA-1 que el usuario está tratando de enviar. Si el script update sale con un código distinto de cero, solo esa referencia es rechazada; otras referencias aún pueden ser actualizadas.
El gancho post-receive se ejecuta después de que se completa todo el proceso y puede usarse para actualizar otros servicios o notificar a los usuarios. Toma los mismos datos de stdin que el gancho pre-receive. Los ejemplos incluyen enviar un correo electrónico a una lista, notificar a un servidor de integración continua o actualizar un sistema de seguimiento de tickets: incluso puede analizar los mensajes de commit para ver si algún ticket necesita ser abierto, modificado o cerrado. Este script no puede detener el proceso de envío, pero el cliente no se desconecta hasta que se haya completado, así que tenga cuidado si intenta hacer algo que pueda llevar mucho tiempo.
|
Tip
|
Si está escribiendo un script/gancho que otros necesitarán leer, prefiera las versiones largas de las banderas de la línea de comandos; dentro de seis meses nos lo agradecerá. |