Puntos de enganche Git
Los hooks de Git son scripts que se ejecutan automáticamente cada vez que se produce un evento concreto en un repositorio de Git. Permiten personalizar el comportamiento interno de Git y desencadenar acciones personalizables en puntos clave del ciclo de vida del desarrollo.
Algunos casos de uso comunes de los hooks de Git son fomentar una política de confirmación, modificar el entorno del proyecto en función del estado del repositorio e implementar flujos de trabajo de integración continua. No obstante, dado que los scripts son infinitamente personalizables, puedes usar hooks de Git para automatizar u optimizar prácticamente cualquier aspecto de tu flujo de trabajo de desarrollo.
En este artículo, comenzaremos con un resumen de conceptos del funcionamiento de los hooks de Git. A continuación, analizaremos algunos de los hooks más populares que pueden usarse tanto en repositorios locales como en repositorios en servidor.
Resumen de conceptos
Todos los hooks de Git son scripts comunes que Git ejecuta cuando se producen determinados eventos en el repositorio. Esto hace que sean muy fáciles de instalar y configurar.
Los hooks pueden residir en repositorios locales o en repositorios en servidor y solo se ejecutan en respuesta a las acciones que se producen en esos repositorios. Más adelante en este artículo nos fijaremos específicamente en las categorías de hooks. La configuración que se describe en el resto de esta sección corresponde tanto a los hooks locales como a los hooks de servidor.
Instalación de hooks
Los hooks residen en el directorio .git/hooks de cada repositorio de Git. Git rellena automáticamente este directorio con scripts de ejemplo cuando inicializas un repositorio. Si echas un vistazo dentro de .git/hooks, verás los archivos siguientes:
applypatch-msg.sample pre-push.sample
commit-msg.sample pre-rebase.sample
post-update.sample prepare-commit-msg.sample
pre-applypatch.sample update.sample
pre-commit.sample
Material relacionado
Cómo mover un repositorio de Git completo
VER LA SOLUCIÓN
Aprende a usar Git con Bitbucket Cloud
Estos archivos representan a la mayoría de los hooks disponibles, pero la extensión .sample impide que se ejecuten de forma predeterminada. Para "instalar" un hook, tan solo debes quitar la extensión .sample . O bien, si escribes un nuevo script desde cero, basta con que añadas un archivo nuevo que coincida con uno de los nombres de archivo anteriores, pero sin la extensión .sample .
A modo de ejemplo, prueba a instalar un hook simple prepare-commit-msg. Quítale la extensión .sample y añade lo siguiente al archivo:
#!/bin/sh
echo "# Please include a useful commit message!" > $1Los hooks deben poder ejecutarse, por lo que es posible que tengas que cambiar los permisos de archivo del script si lo creas desde cero. Por ejemplo, para asegurarte de que prepare-commit-msg pueda ejecutarse, debes ejecutar el siguiente comando:
chmod +x prepare-commit-msgDeberías ver este mensaje en lugar del mensaje de confirmación predeterminado cada vez que ejecutes git commit. Veremos más detenidamente cómo funciona esto en la sección Prepare Commit Message. Por ahora, vamos a divertirnos personalizando algunas de las funciones internas de Git.
Los scripts de ejemplo integrados son referencias muy útiles, ya que documentan los parámetros que se pasan a cada hook (varían de un hook a otro).
Lenguajes de scripting
Los scripts integrados son en su mayoría scripts de shell y PERL, pero puedes usar cualquier lenguaje de scripting que quieras siempre que se pueda ejecutar como archivo ejecutable. La línea shebang (#!/bin/sh) de cada script define cómo se debe interpretar el archivo. Por lo tanto, para usar un lenguaje diferente, tan solo debes cambiarla por la ruta de tu intérprete.
Por ejemplo, podemos escribir un script ejecutable de Python en el archivo prepare-commit-msg en lugar de usar comandos de shell. El siguiente hook hará lo mismo que el script de shell de la sección anterior.
#!/usr/bin/env python
import sys, os
commit_msg_filepath = sys.argv[1]
with open(commit_msg_filepath, 'w') as f:
f.write("# Please include a useful commit message!")Observa que la primera línea ha cambiado para apuntar al intérprete de Python. Además, en lugar de usar $1 para acceder al primer argumento pasado al script, hemos utilizado sys.argv[1] (también ofreceremos más información sobre esto en breve).
Se trata de una función muy eficaz para los hooks de Git porque te permite trabajar en el lenguaje quieras.
Alcance de los hooks
Los hooks son locales para cualquier repositorio de Git determinado y no se copian en el nuevo repositorio cuando ejecutas git clone. Además, dado que son locales, cualquier persona con acceso al repositorio los puede modificar.
Esto tiene un impacto importante cuando se configuran hooks para un equipo de desarrolladores. En primer lugar, debes encontrar una manera de asegurarte de que los hooks se mantengan actualizados entre los miembros de tu equipo. En segundo lugar, no puedes obligar a los desarrolladores a crear confirmaciones de un cierto tipo; solo puedes animarlos a que lo hagan.
Mantener hooks para un equipo de desarrolladores puede ser un poco complicado porque el directorio .git/hooks no se clona con el resto de tu proyecto, ni está bajo control de versiones. Una solución simple para estos dos problemas es almacenar los hooks en el directorio del proyecto real (por encima del directorio .git ). Esto te permite editarlos como cualquier otro archivo con control de versiones. Para instalar el hook, puedes crear un symlink que apunte a él en .git/hooks, o simplemente puedes copiarlo y pegarlo en el directorio .git/hooks siempre que se actualice el hook.
Como alternativa, Git también proporciona un mecanismo de directorio de plantillas que facilita la instalación automática de hooks. Todos los archivos y directorios incluidos en este directorio de plantillas se copian en el directorio .git cada vez que usas git init o git clone.
El propietario de un repositorio puede modificar (o desinstalar por completo) todos los hooks locales que se describen a continuación. Cada miembro del equipo es libre de decidir si quiere usar o no un hook. Así pues, más que una política obligatoria de desarrollo de aplicación, los hooks de Git son una práctica herramienta para desarrolladores.
Sin embargo, es posible rechazar las confirmaciones que no se ajusten a algún estándar utilizando hooks de servidor. Lo veremos en mayor detalle más adelante en el artículo.
Hooks locales
Los hooks locales afectan solo al repositorio en el que residen. Al leer esta sección, recuerda que cada desarrollador puede modificar sus propios hooks locales, por lo que no puedes usarlos para aplicar una política de confirmación. No obstante, los hooks facilitan a los desarrolladores el cumplimiento de determinadas directrices. En esta sección, veremos 6 de los hooks locales más útiles:
pre-commitprepare-commit-msgcommit-msgpost-commitpost-checkoutpre-rebase
Los 4 primeros hooks te permiten conectarte a todo el ciclo de vida de la confirmación, mientras que los 2 últimos sirven para realizar acciones o comprobaciones de seguridad adicionales para los comandos git checkout y git rebase, respectivamente.
Todos los hooks -pre te permiten modificar la acción que está a punto de producirse, mientras que los hooks -post se usan solo para las notificaciones.
También veremos algunas técnicas útiles para analizar argumentos de hook y solicitar información sobre el repositorio mediante comandos de Git de nivel inferior.
Pre-Commit
El script de pre-commit se ejecuta cada vez que ejecutas git commit antes de que Git pida al desarrollador un mensaje de confirmación o genere un objeto de confirmación. Puedes usar este hook para inspeccionar la instantánea que está a punto de confirmarse. Por ejemplo, puede ser útil ejecutar pruebas automatizadas para asegurarse de que la confirmación no rompa ninguna funcionalidad existente.
No se pasa ningún argumento al script de pre-commit y salir con un estado distinto de cero anula toda la confirmación. Echemos un vistazo a una versión simplificada (y más larga) del hook pre-commit integrado. Este script anula la confirmación si encuentra algún error de espacio en blanco, tal como se define en el comando git diff-index (los espacios en blanco finales, las líneas que solo tienen espacios en blanco y un espacio seguido de una tabulación dentro de la sangría inicial de una línea se consideran errores de forma predeterminada).
#!/bin/sh
# Check if this is the initial commit
if git rev-parse --verify HEAD >/dev/null 2>&1
then
echo "pre-commit: About to create a new commit..."
against=HEAD
else
echo "pre-commit: About to create the first commit..."
against=4b825dc642cb6eb9a060e54bf8d69288fbee4904
fi
# Use git diff-index to check for whitespace errors
echo "pre-commit: Testing for whitespace errors..."
if ! git diff-index --check --cached $against
then
echo "pre-commit: Aborting commit due to whitespace errors"
exit 1
else
echo "pre-commit: No whitespace errors :)"
exit 0
fiPara poder usar git diff-index, necesitamos averiguar con qué referencia de confirmación estamos comparando el índice. Suele ser HEAD, pero HEAD no existe al crear la confirmación inicial, por lo que nuestra primera tarea es tener en cuenta este caso extremo. Para ello, usamos git rev-parse --verify, que simplemente comprueba si el argumento (HEAD) es una referencia válida o no. La parte >/dev/null 2>&1 silencia cualquier salida de git rev-parse. HEAD o un objeto de confirmación vacío se almacenan en la variable against para usarse con git diff-index. El hash 4b825d... es un ID de confirmación mágico que representa una confirmación vacía.
El comando git diff-index --cached compara una confirmación con el índice. Al pasar la opción --check, le pedimos que nos avise si los cambios introducen errores de espacio en blanco. Si es así, anulamos la confirmación devolviendo un estado de salida de 1; de lo contrario, salimos con 0 y el flujo de trabajo de confirmación continúa con normalidad.
Este es solo un ejemplo del hook pre-commit. Utiliza comandos de Git existentes para ejecutar pruebas en los cambios introducidos por la confirmación propuesta, pero puedes hacer lo que quieras en pre-commit; por ejemplo, ejecutar otros scripts o un conjunto de pruebas de terceros, o bien comprobar el estilo del código con Lint.
Prepare Commit Message
El hook prepare-commit-msg se llama después del hook pre-commit para rellenar el editor de texto con un mensaje de confirmación. Sirve para modificar los mensajes de confirmación generados automáticamente para las confirmaciones combinadas o fusionadas.
Se pasan de uno a tres argumentos al script de prepare-commit-msg:
1. El nombre de un archivo temporal que contiene el mensaje. Cambias el mensaje de confirmación modificando este archivo in situ.
2. El tipo de confirmación. Puede ser message (opción -m o -F), template (opción -t), merge (si la confirmación es una confirmación de fusión) o squash (si la confirmación se combina con otras confirmaciones).
3. El hash SHA1 de la confirmación relevante. Solo se da si se dio la opción -c, -C o —amend.
Igual que ocurre con pre-commit, salir con un estado distinto de cero anula la confirmación.
Ya hemos visto un ejemplo sencillo que editaba el mensaje de confirmación, pero echemos un vistazo a un script más útil. Cuando se utiliza un gestor de incidencias, una práctica habitual es abordar cada incidencia en una rama distinta. Si incluyes el número de incidencia en el nombre de la rama, puedes escribir un hook prepare-commit-msg para que se incluya automáticamente en cada mensaje de confirmación en esa rama.
#!/usr/bin/env python
import sys, os, re
from subprocess import check_output
# Collect the parameters
commit_msg_filepath = sys.argv[1]
if len(sys.argv) > 2:
commit_type = sys.argv[2]
else:
commit_type = ''
if len(sys.argv) > 3:
commit_hash = sys.argv[3]
else:
commit_hash = ''
print "prepare-commit-msg: File: %s\nType: %s\nHash: %s" % (commit_msg_filepath, commit_type, commit_hash)
# Figure out which branch we're on
branch = check_output(['git', 'symbolic-ref', '--short', 'HEAD']).strip()
print "prepare-commit-msg: On branch '%s'" % branch
# Populate the commit message with the issue #, if there is one
if branch.startswith('issue-'):
print "prepare-commit-msg: Oh hey, it's an issue branch."
result = re.match('issue-(.*)', branch)
issue_number = result.group(1)
with open(commit_msg_filepath, 'r+') as f:
content = f.read()
f.seek(0, 0)
f.write("ISSUE-%s %s" % (issue_number, content))Primero, el hook prepare-commit-msg anterior te muestra cómo recopilar todos los parámetros que se pasan al script. Luego, llama a git symbolic-ref --short HEAD para obtener el nombre de la rama que corresponde a HEAD. Si este nombre de rama comienza por issue-, vuelve a escribir el contenido del archivo del mensaje de confirmación para incluir el número de incidencia en la primera línea. Por lo tanto, si el nombre de tu rama es issue-224, se generará el siguiente mensaje de confirmación.
ISSUE-224
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch issue-224
# Changes to be committed:
# modified: test.txtAl usar prepare-commit-msg, debe tenerse en cuenta que el hook se ejecuta incluso cuando el usuario pasa un mensaje con la opción -m de git commit. Esto significa que el script anterior insertará automáticamente la cadena ISSUE-[#] sin permitir que el usuario la edite. Puedes gestionar este caso viendo si el segundo parámetro (commit_type) es igual a message.
En cambio, sin la opción -m, el hook prepare-commit-msg sí que permite que el usuario edite el mensaje una vez generado. Por lo tanto, más que una forma de aplicar una política de mensajes de confirmación, es un script útil. Para ello, necesitas el hook commit-msg que veremos en la siguiente sección.
Mensaje de confirmación
El hook commit-msg es muy parecido al hook prepare-commit-msg, pero se llama después de que el usuario introduzca un mensaje de confirmación. Puedes usarlo para advertir a los desarrolladores de que su mensaje no cumple con los estándares de tu equipo.
El único argumento que se pasa a este hook es el nombre del archivo que contiene el mensaje. Si no le gusta el mensaje que ha introducido el usuario, puede modificar este archivo in situ (igual que con prepare-commit-msg) o puede anular la confirmación por completo al salir con un estado distinto de cero.
Por ejemplo, el siguiente script comprueba que el usuario no haya eliminado la cadena ISSUE-[#] generada automáticamente por el hook prepare-commit-msg en la sección anterior.
#!/usr/bin/env python
import sys, os, re
from subprocess import check_output
# Collect the parameters
commit_msg_filepath = sys.argv[1]
# Figure out which branch we're on
branch = check_output(['git', 'symbolic-ref', '--short', 'HEAD']).strip()
print "commit-msg: On branch '%s'" % branch
# Check the commit message if we're on an issue branch
if branch.startswith('issue-'):
print "commit-msg: Oh hey, it's an issue branch."
result = re.match('issue-(.*)', branch)
issue_number = result.group(1)
required_message = "ISSUE-%s" % issue_number
with open(commit_msg_filepath, 'r') as f:
content = f.read()
if not content.startswith(required_message):
print "commit-msg: ERROR! The commit message must start with '%s'" % required_message
sys.exit(1)Si bien se llama a este script cada vez que el usuario crea una confirmación, no debes hacer mucho más que comprobar el mensaje de confirmación. Si necesitas notificar a otros servicios que se ha confirmado una instantánea, es mejor que utilices el hook post-commit.
Post-Commit
El hook post-commit se llama inmediatamente después del hook commit-msg. No puede cambiar el resultado de la operación de git commit, por lo que se usa principalmente para fines de notificación.
El script no usa parámetros y su estado de salida no afecta a la confirmación de ninguna manera. En la mayoría de los scripts de post-commit, es conveniente que tengas acceso a la confirmación que se acaba de crear. Puedes usar git rev-parse HEAD para obtener el hash SHA1 de la nueva confirmación, o puedes usar git log -1 HEAD para obtener toda su información.
Por ejemplo, si quieres enviar un correo electrónico a tu jefe cada vez que confirmes una instantánea (aunque probablemente no sea la mejor idea para la mayoría de los flujos de trabajo), puedes añadir el siguiente hook post-commit.
#!/usr/bin/env python
import smtplib
from email.mime.text import MIMEText
from subprocess import check_output
# Get the git log --stat entry of the new commit
log = check_output(['git', 'log', '-1', '--stat', 'HEAD'])
# Create a plaintext email message
msg = MIMEText("Look, I'm actually doing some work:\n\n%s" % log)
msg['Subject'] = 'Git post-commit hook notification'
msg['From'] = 'mary@example.com'
msg['To'] = 'boss@example.com'
# Send the message
SMTP_SERVER = 'smtp.example.com'
SMTP_PORT = 587
session = smtplib.SMTP(SMTP_SERVER, SMTP_PORT)
session.ehlo()
session.starttls()
session.ehlo()
session.login(msg['From'], 'secretPassword')
session.sendmail(msg['From'], msg['To'], msg.as_string())
session.quit()Es posible usar post-commit para desencadenar un sistema de integración continua local, pero la mayoría de las veces es mejor hacerlo en el hook post-receive. Este hook se ejecuta en el servidor y no en la máquina local del usuario, y también se ejecuta cada vez que un desarrollador envía su código. Esto hace que sea mucho más adecuado para llevar a cabo la integración continua.
Post-Checkout
El hook post-checkout funciona de manera muy similar al hook post-commit, pero se llama siempre que logras extraer una referencia con git checkout. Es muy útil para sacar del directorio de trabajo los archivos generados que podrían provocar confusiones.
Este hook acepta tres parámetros y su estado de salida no afecta al comando git checkout.
1. La referencia del HEAD anterior.
2. La referencia del nuevo HEAD.
3. Una marca que te indica si ha sido una extracción de rama o de archivo. La marca será 1 y 0, respectivamente.
Un problema con el que suelen encontrarse los desarrolladores de Python es que los archivos .pyc generados no desaparecen después de cambiar de rama. El intérprete a veces usa estos archivos .pyc en lugar del archivo de origen .py . Para evitar confusiones, puedes eliminar todos los archivos .pyc cada vez que extraigas una nueva rama mediante el siguiente script de post-checkout:
#!/usr/bin/env python
import sys, os, re
from subprocess import check_output
# Collect the parameters
previous_head = sys.argv[1]
new_head = sys.argv[2]
is_branch_checkout = sys.argv[3]
if is_branch_checkout == "0":
print "post-checkout: This is a file checkout. Nothing to do."
sys.exit(0)
print "post-checkout: Deleting all '.pyc' files in working directory"
for root, dirs, files in os.walk('.'):
for filename in files:
ext = os.path.splitext(filename)[1]
if ext == '.pyc':
os.unlink(os.path.join(root, filename))El directorio de trabajo actual para scripts de hook siempre es la raíz del repositorio, por lo que la llamada a os.walk('.') recorre en iteración todos los archivos del repositorio. Luego, comprobamos su extensión y la eliminamos si es un archivo .pyc .
También puedes utilizar el hook post-checkout para modificar tu directorio de trabajo en función de la rama que hayas extraído. Por ejemplo, puedes usar una rama de plugins para almacenar todos tus complementos fuera del código base principal. Si estos complementos requieren muchos binarios que otras ramas no requieren, puedes generarlos selectivamente solo cuando estés en la rama de plugins.
Pre-Rebase
El hook pre-rebase se llama antes de que git rebase cambie nada, por lo que es ideal para evitar que se produzca algo terrible.
Este hook usa 2 parámetros: la rama de nivel superior desde la que se ha bifurcado la serie y la rama que se ha fusionado mediante cambio de base. El segundo parámetro está vacío cuando se fusiona mediante cambio de base la rama actual. Para anular la fusión mediante cambio de base, sal con un estado distinto de cero.
Por ejemplo, si quieres inhabilitar por completo la fusión mediante cambio de base en tu repositorio, puedes usar el siguiente script de pre-rebase:
#!/bin/sh
# Disallow all rebasing
echo "pre-rebase: Rebasing is dangerous. Don't do it."
exit 1Ahora, cada vez que ejecutes git rebase, verás este mensaje:
pre-rebase: Rebasing is dangerous. Don't do it.
The pre-rebase hook refused to rebase.Para ver un ejemplo más detallado, echa un vistazo al script de pre-rebase.sample que se incluye. Este script es un poco más inteligente a la hora de decidir cuándo se debe inhabilitar la fusión mediante cambio de base. Comprueba si la rama temática que estás intentando fusionar mediante cambio de base ya se ha fusionado en la rama next (que se supone que es la rama principal). Si lo ha hecho, es probable que la fusión mediante cambio de base provoque problemas, por lo que el script la anula.
Hooks de servidor
Los hooks de servidor funcionan igual que los locales, salvo que residen en repositorios del lado del servidor (por ejemplo, un repositorio central o un repositorio público de un desarrollador). Cuando se adjuntan al repositorio oficial, algunos pueden servir para aplicar una política al rechazar ciertas confirmaciones.
En el resto de este artículo hablaremos de 3 hooks de servidor:
pre-receiveActualizarpost-receive
Todos estos hooks te permiten reaccionar a diferentes fases del proceso de git push.
La salida de los hooks de servidor se canaliza a la consola del cliente, por lo que es muy fácil enviar mensajes al desarrollador. Sin embargo, también debes tener en cuenta que estos scripts no devuelven el control del terminal hasta que acaban de ejecutarse, por lo que debes tener cuidado al realizar operaciones de larga duración.
Pre-Receive
El hook pre-receive se ejecuta cada vez que alguien usa git push para enviar confirmaciones al repositorio. Siempre debe residir en el repositorio remoto que es el destino del envío, no en el repositorio de origen.
El hook se ejecuta antes de que se actualicen las referencias, por lo que es muy útil para aplicar cualquier tipo de política de desarrollo. Si no te gusta quién hace el envío, el formato del mensaje de confirmación o los cambios que se incluyen en la confirmación, puedes rechazar la confirmación. Aunque no puedes evitar que los desarrolladores realicen confirmaciones con formato incorrecto, puedes impedir que estas confirmaciones entren en la base de código oficial rechazándolas con pre-receive.
El script no usa parámetros, pero cada referencia que se envía se pasa al script en una línea distinta en la entrada estándar con el siguiente formato:
<old-value> <new-value> <ref-name>Para ver cómo funciona este hook, puedes usar un script de pre-receive muy básico que simplemente lea las referencias enviadas y las imprima.
#!/usr/bin/env python
import sys
import fileinput
# Read in each ref that the user is trying to update
for line in fileinput.input():
print "pre-receive: Trying to push ref: %s" % line
# Abort the push
# sys.exit(1)De nuevo, este hook es un poco diferente a los demás porque la información se pasa al script a través de una entrada estándar y no como argumentos de línea de comandos. Después de colocar el script anterior en el directorio .git/hooks de un repositorio remoto y enviar la rama main, verás un código parecido a este en tu consola:
b6b36c697eb2d24302f89aa22d9170dfe609855b 85baa88c22b52ddd24d71f05db31f4e46d579095 refs/heads/mainPuedes usar estos hashes SHA1, junto con algunos comandos de Git de nivel inferior, para inspeccionar los cambios que se van a introducir. Estos son algunos de los casos de uso más comunes:
- Rechazar cambios que impliquen una fusión mediante cambio de base de nivel superior
- Evitar fusiones sin avance rápido
- Comprobar que el usuario tiene los permisos correctos para realizar los cambios deseados (se usa principalmente para flujos de trabajo centralizados de Git)
Si se envían varias referencias, al devolver un estado distinto de cero desde pre-receive, se anulan todas. Si quieres aceptar o rechazar ramas de una en una, debes usar el hook update.
Actualizar
El hook update se llama después de pre-receive y funciona de forma muy parecida. Se llama incluso antes de que se actualice nada, pero se llama por separado para cada referencia enviada. Esto significa que si el usuario intenta enviar 4 ramas, update se ejecuta 4 veces. A diferencia de pre-receive, este hook no necesita leer desde la entrada estándar. En cambio, acepta los 3 argumentos siguientes:
1. El nombre de la referencia que se está actualizando
2. El nombre del objeto antiguo almacenado en la referencia
3. El nombre del objeto nuevo almacenado en la referencia
Es la misma información que se pasa a pre-receive, pero dado que update se invoca por separado para cada referencia, puedes rechazar algunas referencias y permitir otras.
#!/usr/bin/env python
import sys
branch = sys.argv[1]
old_commit = sys.argv[2]
new_commit = sys.argv[3]
print "Moving '%s' from %s to %s" % (branch, old_commit, new_commit)
# Abort pushing only this branch
# sys.exit(1)El hook update anterior simplemente envía la rama y los hashes de confirmación antiguos y nuevos. Al enviar más de una rama al repositorio remoto, verás que se ejecuta la instrucción print para cada rama.
Post-Receive
El hook post-receive se llama después de una operación de envío exitosa, por lo que es ideal para las notificaciones. En muchos flujos de trabajo, este hook resulta más adecuado para desencadenar notificaciones que post-commit, ya que los cambios están disponibles en un servidor público en lugar de residir solo en el equipo local del usuario. Enviar correos electrónicos a otros desarrolladores y desencadenar un sistema de integración continua son casos de uso comunes de post-receive.
El script no usa parámetros, pero recibe la misma información que pre-receive a través de la entrada estándar.
Resumen
En este artículo hemos aprendido cómo se pueden usar los hooks de Git para modificar el comportamiento interno y recibir notificaciones cuando se producen determinados eventos en un repositorio. Los hooks son scripts comunes que residen en el repositorio .git/hooks , lo que hace que sean muy fáciles de instalar y personalizar.
También hemos visto algunos de los hooks locales y de servidor más comunes, que nos permiten conectarnos a todo el ciclo de vida del desarrollo. Ahora sabemos cómo realizar acciones personalizables en cada fase del proceso de creación de confirmaciones, así como en el proceso git push. Con solo unas nociones de lenguaje de scripting, estos hooks te permitirán hacer prácticamente cualquier cosa que puedas imaginar con un repositorio de Git.
Compartir este artículo
Tema siguiente
Lecturas recomendadas
Consulta estos recursos para conocer los tipos de equipos de DevOps o para estar al tanto de las novedades sobre DevOps en Atlassian.
Blog de Bitbucket
Ruta de aprendizaje de DevOps
