Git
Manos

Sintaxis

• .git / hooks / applypatch-msg
• .git / hooks / commit-msg
• .git / hooks / post-update
• .git / hooks / pre-applypatch
• .git / hooks / pre-commit
• .git / hooks / prepare-commit-msg
• .git / ganchos / pre-empuje
• .git / hooks / pre-rebase
• .git / hooks / update

Observaciones

Confirmacion de mensajes

Este enlace es similar al prepare-commit-msg , pero se llama después de que el usuario ingresa un mensaje de confirmación en lugar de antes. Esto generalmente se usa para advertir a los desarrolladores si su mensaje de confirmación está en un formato incorrecto.

El único argumento pasado a este gancho es el nombre del archivo que contiene el mensaje. Si no le gusta el mensaje que ha ingresado el usuario, puede modificar este archivo en el lugar (igual que prepare-commit-msg ) o puede abortar la confirmación completamente al salir con un estado distinto de cero.

El siguiente ejemplo se usa para verificar si la palabra ticket seguido de un número está presente en el mensaje de confirmación

word="ticket [0-9]"
isPresent=$(grep -Eoh "$word" $1)

if [[ -z $isPresent ]]
  then echo "Commit message KO, $word is missing"; exit 1;
  else echo "Commit message OK"; exit 0;
fi

Ganchos locales

Los enlaces locales solo afectan a los repositorios locales en los que residen. Cada desarrollador puede alterar sus propios enlaces locales, por lo que no se pueden usar de manera confiable como una forma de hacer cumplir una política de confirmación. Están diseñados para facilitar a los desarrolladores el cumplimiento de ciertas pautas y evitar posibles problemas en el futuro.

Hay seis tipos de enlaces locales: pre-commit, prepare-commit-msg, commit-msg, post-commit, post-checkout y pre-rebase.

Los primeros cuatro ganchos se relacionan con los compromisos y le permiten tener cierto control sobre cada parte en el ciclo de vida de un compromiso. Los dos últimos le permiten realizar algunas acciones adicionales o verificaciones de seguridad para los comandos git checkout y git rebase.

Todos los "pre" ganchos le permiten alterar la acción que está a punto de realizarse, mientras que los "post-" ganchos se usan principalmente para notificaciones.

Después de la salida

Este enganche funciona de manera similar al enganche post-commit , pero se llama siempre que verifique una referencia con git checkout . Esta podría ser una herramienta útil para limpiar su directorio de trabajo de archivos generados automáticamente que de otra manera podrían causar confusión.

Este gancho acepta tres parámetros:

1. la referencia de la anterior CABEZA,
2. el ref de la nueva CABEZA, y
3. un indicador que indica si se trata de una verificación de sucursal o de un archivo ( 1 o 0 , respectivamente).

Su estado de salida no tiene efecto en el comando git checkout .

Post-commit

Este enlace se llama inmediatamente después del commit-msg . No puede alterar el resultado de la operación de git commit , por lo tanto, se utiliza principalmente para fines de notificación.

El script no toma parámetros, y su estado de salida no afecta a la confirmación de ninguna manera.

Después de recibir

Este gancho se llama después de una operación de empuje exitosa. Normalmente se utiliza para fines de notificación.

El script no toma parámetros, pero se envía la misma información que pre-receive través de la entrada estándar:

<old-value> <new-value> <ref-name>

Pre cometido

Este gancho se ejecuta cada vez que ejecutas git commit , para verificar qué está a punto de comprometerse. Puede utilizar este enlace para inspeccionar la instantánea que está a punto de confirmarse.

Este tipo de enlace es útil para ejecutar pruebas automatizadas para asegurarse de que el compromiso entrante no rompa la funcionalidad existente de su proyecto. Este tipo de gancho también puede verificar errores de espacio en blanco o EOL.

No se pasa ningún argumento a la secuencia de comandos de pre-confirmación, y salir con un estado distinto de cero anula la confirmación completa.

Prepare-commit-msg

Este enganche se llama después del enganche de pre-commit para rellenar el editor de texto con un mensaje de confirmación. Esto se usa normalmente para alterar los mensajes de confirmación generados automáticamente para confirmaciones aplastadas o fusionadas.

De uno a tres argumentos se pasan a este gancho:

• El nombre de un archivo temporal que contiene el mensaje.
• El tipo de commit, ya sea
  • mensaje (opción -m o -F ),
  • plantilla (opción -t ),
  • fusionar (si es un commit de fusión), o
  • Squash (si está aplastando otros commit).
• El hash SHA1 del commit relevante. Esto solo se da si se dio la opción -c , -C o --amend .

Similar a pre-commit , salir con un estado distinto de cero anula el commit.

Pre-rebase

Este gancho se llama antes de que git rebase comience a alterar la estructura del código. Este gancho se usa normalmente para asegurarse de que una operación de rebase sea apropiada.

Este gancho lleva 2 parámetros:

1. la rama aguas arriba de la que se bifurcó la serie, y
2. la rama se está rebasando (vacía cuando se rebasa la rama actual).

Puede abortar la operación de rebase al salir con un estado distinto de cero.

Pre-recepción

Este gancho se ejecuta cada vez que alguien usa git push para empujar confirmaciones al repositorio. Siempre reside en el repositorio remoto que es el destino del envío y no en el repositorio original (local).

El gancho se ejecuta antes de que se actualicen las referencias. Normalmente se utiliza para hacer cumplir cualquier tipo de política de desarrollo.

El script no toma parámetros, pero cada referencia que se está empujando pasa al script en una línea separada en la entrada estándar en el siguiente formato:

<old-value> <new-value> <ref-name>

Actualizar

Este gancho se llama después de pre-receive y funciona de la misma manera. Se llama antes de que realmente se actualice algo, pero se llama por separado para cada referencia que fue empujada en lugar de todas las referencias a la vez.

Este gancho acepta los siguientes 3 argumentos:

• nombre de la referencia que se actualiza,
• antiguo nombre de objeto almacenado en la referencia, y
• Nuevo nombre de objeto almacenado en la ref.

Esta es la misma información que se pasa a pre-receive , pero como la update se invoca por separado para cada referencia, puede rechazar algunas referencias mientras permite otras.

Pre-empuje

Disponible en Git 1.8.2 y superior.

#!/bin/bash

protected_branch='master'  
current_branch=$(git symbolic-ref HEAD | sed -e 's,.*/\(.*\),\1,')

if [ $protected_branch = $current_branch ]  
then  
    read -p "You're about to push master, is that what you intended? [y|n] " -n 1 -r < /dev/tty
    echo
    if echo $REPLY | grep -E '^[Yy]$' > /dev/null
    then
        exit 0 # push will execute
    fi
    exit 1 # push will not execute
else  
    exit 0 # push will execute
fi  

#!/usr/bin/env ruby
require 'pty'
html_path = "rspec_results.html"
begin
  PTY.spawn( "rspec spec --format h > rspec_results.html" ) do |stdin, stdout, pid|
  begin
    stdin.each { |line| print line }
  rescue Errno::EIO
  end
end
rescue PTY::ChildExited
  puts "Child process exit!"
end

# find out if there were any errors  
html = open(html_path).read
examples = html.match(/(\d+) examples/)[0].to_i rescue 0
errors = html.match(/(\d+) errors/)[0].to_i rescue 0
if errors == 0 then
  errors = html.match(/(\d+) failure/)[0].to_i rescue 0
end
pending = html.match(/(\d+) pending/)[0].to_i rescue 0

if errors.zero?
  puts "0 failed! #{examples} run, #{pending} pending"
  # HTML Output when tests ran successfully:
  # puts "View spec results at #{File.expand_path(html_path)}"
  sleep 1
  exit 0
else
  puts "\aCOMMIT FAILED!!"
  puts "View your rspec results at #{File.expand_path(html_path)}"
  puts
  puts "#{errors} failed! #{examples} run, #{pending} pending"
  # Open HTML Ooutput when tests failed
  # `open #{html_path}`
  exit 1
end

Verifique la compilación de Maven (u otro sistema de compilación) antes de confirmar

.git/hooks/pre-commit

#!/bin/sh
if [ -s pom.xml ]; then
    echo "Running mvn verify"
    mvn clean verify
    if [ $? -ne 0 ]; then
        echo "Maven build failed"
        exit 1
    fi
fi

Reenviar automáticamente ciertos empujes a otros repositorios.

post-receive se pueden usar para reenviar automáticamente los envíos entrantes a otro repositorio.

$ cat .git/hooks/post-receive

#!/bin/bash

IFS=' '
while read local_ref local_sha remote_ref remote_sha
do

  echo "$remote_ref" | egrep '^refs\/heads\/[A-Z]+-[0-9]+$' >/dev/null && {
    ref=`echo $remote_ref | sed -e 's/^refs\/heads\///'`
    echo Forwarding feature branch to other repository: $ref
    git push -q --force other_repos $ref
  }

done

En este ejemplo, el egrep regexp busca un formato de rama específico (aquí: JIRA-12345 como se usa para nombrar problemas de Jira). Puede dejar esta parte desactivada si desea reenviar todas las sucursales, por supuesto.