Git
Crochets

Syntaxe

• .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 / hooks / pre-push
• .git / hooks / pre-rebase
• .git / hooks / update

Remarques

Commit-msg

Ce hook est similaire au hook prepare-commit-msg , mais il est appelé après que l'utilisateur ait entré un message de validation plutôt qu'avant. Ceci est généralement utilisé pour avertir les développeurs si leur message de validation est dans un format incorrect.

Le seul argument transmis à ce hook est le nom du fichier contenant le message. Si vous n'aimez pas le message que l'utilisateur a entré, vous pouvez modifier ce fichier sur place (comme prepare-commit-msg ) ou vous pouvez abandonner la validation entièrement en quittant avec un statut différent de zéro.

L'exemple suivant permet de vérifier si le mot ticket suivi d'un numéro est présent dans le message de validation

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

Crochets locaux

Les hooks locaux n'affectent que les référentiels locaux dans lesquels ils résident. Chaque développeur peut modifier ses propres hooks locaux, de sorte qu'ils ne peuvent pas être utilisés de manière fiable pour appliquer une stratégie de validation. Ils sont conçus pour faciliter le respect de certaines directives par les développeurs et éviter des problèmes potentiels ultérieurement.

Il existe six types de hooks locaux: pre-commit, prepare-commit-msg, commit-msg, post-commit, post-checkout et pre-rebase.

Les quatre premiers crochets concernent les commits et vous permettent de contrôler chaque partie du cycle de vie d'un engagement. Les deux derniers vous permettent d’effectuer des actions supplémentaires ou des contrôles de sécurité pour les commandes git checkout et git rebase.

Tous les "pré-hooks" vous permettent de modifier l'action qui est sur le point de se dérouler, tandis que les "post-hooks" sont principalement utilisés pour les notifications.

Post-caisse

Ce hook fonctionne de manière similaire au hook post-commit , mais il est appelé chaque fois que vous récupérez une référence avec git checkout . Cela pourrait être un outil utile pour effacer votre répertoire de travail des fichiers générés automatiquement qui, sinon, causeraient de la confusion.

Ce hook accepte trois paramètres:

1. la référence de la précédente tête,
2. le ref de la nouvelle HEAD, et
3. un indicateur indiquant s'il s'agissait d'une extraction de branche ou d'une extraction de fichier ( 1 ou 0 , respectivement).

Son état de sortie n'a aucun effet sur la git checkout .

Post-commit

Ce hook est appelé immédiatement après le hook commit-msg . Il ne peut pas modifier le résultat de l'opération de git commit , il est donc principalement utilisé à des fins de notification.

Le script ne prend aucun paramètre et son statut de sortie n'affecte en rien la validation.

Post-recevoir

Ce hook est appelé après une opération Push réussie. Il est généralement utilisé à des fins de notification.

Le script ne prend aucun paramètre, mais reçoit la même information que la pre-receive via l'entrée standard:

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

Pré-engagement

Ce hook est exécuté à chaque fois que vous lancez git commit , pour vérifier ce qui va être commis. Vous pouvez utiliser ce hook pour inspecter le snapshot sur le point d'être validé.

Ce type de hook est utile pour exécuter des tests automatisés pour vous assurer que le commit entrant ne rompt pas les fonctionnalités existantes de votre projet. Ce type de hook peut également vérifier les erreurs d'espacement ou d'EOL.

Aucun argument n'est transmis au script de pré-validation et quitter avec un statut non nul interrompt la validation entière.

Prepare-commit-msg

Ce hook est appelé après le hook pre-commit pour remplir l'éditeur de texte avec un message de validation. Ceci est généralement utilisé pour modifier les messages de validation générés automatiquement pour les commits écrasés ou fusionnés.

Un à trois arguments sont passés à ce hook:

• Nom d'un fichier temporaire contenant le message.
• Le type de commit, soit
  • message (option -m ou -F ),
  • template (option -t ),
  • fusionner (si c'est un commit de fusion), ou
  • squash (s'il écrase d'autres commits).
• Le hachage SHA1 du commit concerné. Ceci n'est donné que si l' --amend -c , -C ou --amend été donnée.

Semblable à la pre-commit , quitter avec un statut non nul interrompt la validation.

Pré-rebase

Ce hook est appelé avant que git rebase commence à modifier la structure du code. Ce crochet est généralement utilisé pour s'assurer qu'une opération de rebase est appropriée.

Ce hook prend 2 paramètres:

1. la branche en amont que la série a été fourchue, et
2. la branche étant rebasée (vide lors du rebasage de la branche en cours).

Vous pouvez abandonner l'opération de rebase en quittant avec un statut différent de zéro.

Pré-recevoir

Ce hook est exécuté chaque fois que quelqu'un utilise git push pour pousser des commits vers le référentiel. Il réside toujours dans le référentiel distant qui est la destination de la distribution et non dans le référentiel (local) d'origine.

Le hook s'exécute avant toute mise à jour des références. Il est généralement utilisé pour appliquer tout type de politique de développement.

Le script ne prend aucun paramètre, mais chaque ref est envoyé au script sur une ligne distincte sur l'entrée standard au format suivant:

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

Mettre à jour

Ce crochet est appelé après la pre-receive et fonctionne de la même manière. Il est appelé avant que quelque chose ne soit réellement mis à jour, mais il est appelé séparément pour chaque ref que l'on a poussé plutôt que pour toutes les références à la fois.

Ce hook accepte les 3 arguments suivants:

• nom de la référence en cours de mise à jour,
• ancien nom d'objet stocké dans la référence, et
• nouveau nom d'objet stocké dans la ref.

C'est la même information transmise à la pre-receive , mais puisque la update est appelée séparément pour chaque ref, vous pouvez rejeter certaines références tout en en autorisant d'autres.

Pré-pousser

Disponible dans Git 1.8.2 et supérieur.

#!/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

Vérifier la construction Maven (ou un autre système de construction) avant de valider

.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

Transférer automatiquement certaines poussées vers d'autres référentiels

post-receive ancrage post-receive peuvent être utilisés pour transférer automatiquement les envois entrants vers un autre référentiel.

$ 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

Dans cet exemple, l' egrep rationnelle egrep recherche un format de branche spécifique (ici: JIRA-12345 utilisé pour nommer les problèmes Jira). Vous pouvez laisser cette partie si vous voulez transférer toutes les branches, bien sûr.