Git
Haken

Syntax

• .git / hooks / applypatch-msg
• .git / hooks / commit-msg
• .git / hooks / post-update
• .git / hooks / Pre-Applypatch
• .git / hooks / pre-commit
• .git / hooks / prepar-commit-msg
• .git / hooks / pre-push
• .git / hooks / pre-rebase
• .git / hooks / update

Bemerkungen

Commit-msg

Dieser Hook ähnelt dem Hook " prepare-commit-msg , wird jedoch aufgerufen, nachdem der Benutzer eine Commit-Nachricht eingegeben hat. Dies wird normalerweise verwendet, um Entwickler zu warnen, wenn ihre Commit-Nachricht ein falsches Format hat.

Das einzige an diesen Hook übergebene Argument ist der Name der Datei, die die Nachricht enthält. Wenn Ihnen die vom Benutzer eingegebene Nachricht nicht gefällt, können Sie diese Datei entweder direkt ändern (wie bei prepare-commit-msg ), oder Sie können den Commit vollständig abbrechen, indem Sie den Status mit einem anderen Status als null beenden.

Das folgende Beispiel wird verwendet, um zu überprüfen, ob das Wort Ticket gefolgt von einer Nummer in der Festschreibungsnachricht vorhanden ist

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

Lokale Haken

Lokale Hooks wirken sich nur auf die lokalen Repositorys aus, in denen sie sich befinden. Jeder Entwickler kann seine eigenen lokalen Hooks ändern, sodass er nicht zuverlässig verwendet werden kann, um eine Commit-Richtlinie durchzusetzen. Sie sollen Entwicklern die Einhaltung bestimmter Richtlinien erleichtern und mögliche Probleme auf der Straße vermeiden.

Es gibt sechs Arten von lokalen Hooks: Pre-Commit, Prepare-Commit-Msg, Commit-Msg, Post-Commit, Post-Checkout und Pre-Rebase.

Die ersten vier Haken beziehen sich auf Commits und geben Ihnen die Kontrolle über jeden Teil des Lebenszyklus eines Commits. In den letzten beiden Fällen können Sie einige zusätzliche Aktionen oder Sicherheitsüberprüfungen für die Befehle git checkout und git rebase durchführen.

Bei allen "Pre-" -Hooks können Sie die Aktion ändern, die gerade ausgeführt wird, während die "Post-" - Hooks hauptsächlich für Benachrichtigungen verwendet werden.

Post-Checkout

Dieser Hook funktioniert ähnlich wie der Hook nach dem post-commit , er wird jedoch immer dann aufgerufen, wenn Sie eine Referenz mit git checkout erfolgreich git checkout . Dies kann ein nützliches Werkzeug sein, um das Arbeitsverzeichnis von automatisch generierten Dateien zu löschen, was sonst zu Verwirrung führen würde.

Dieser Haken akzeptiert drei Parameter:

1. der Ref des vorherigen HEAD,
2. der Ref des neuen HEAD und
3. ein Flag, das angibt, ob es sich um eine Zweigkasse oder um eine Dateikasse handelt ( 1 oder 0 ).

Der Exit-Status hat keinen Einfluss auf den Befehl git checkout .

Post-Commit

Dieser Hook wird unmittelbar nach dem commit-msg Hook aufgerufen. Es kann das Ergebnis der git commit nicht ändern. Daher wird es hauptsächlich für Benachrichtigungszwecke verwendet.

Das Skript nimmt keine Parameter an, und sein Beendigungsstatus wirkt sich in keiner Weise auf das Festschreiben aus.

Post empfangen

Dieser Hook wird nach einer erfolgreichen Push-Operation aufgerufen. Es wird normalerweise zu Benachrichtigungszwecken verwendet.

Das Skript nimmt keine Parameter an, erhält jedoch die gleichen Informationen wie pre-receive per Standardeingabe:

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

Pre-Commit

Dieser Hook wird jedes Mal ausgeführt, wenn Sie git commit ausführen, um zu überprüfen, was gerade festgeschrieben wird. Mit diesem Hook können Sie die Momentaufnahme überprüfen, die gerade festgeschrieben wird.

Dieser Hook-Typ ist für die Ausführung automatisierter Tests hilfreich, um sicherzustellen, dass die eingehende Festschreibung die vorhandene Funktionalität Ihres Projekts nicht beeinträchtigt. Dieser Hook-Typ kann auch nach Whitespace- oder EOL-Fehlern suchen.

Es werden keine Argumente an das Pre-Commit-Skript übergeben, und das Beenden mit einem Nicht-Null-Status bricht das gesamte Commit ab.

Prepare-Commit-msg

Dieser Hook wird nach dem pre-commit Hook aufgerufen, um den Texteditor mit einer Commit-Nachricht zu füllen. Dies wird normalerweise verwendet, um die automatisch generierten Commit-Nachrichten für komprimierte oder zusammengeführte Commits zu ändern.

Ein bis drei Argumente werden an diesen Hook übergeben:

• Der Name einer temporären Datei, die die Nachricht enthält.
• Die Art des Commits entweder
  • Nachricht (Option -m oder -F ),
  • Vorlage (Option -t ),
  • merge (wenn es sich um ein Merge-Commit handelt) oder
  • squash (wenn andere Commits gequetscht werden).
• Der SHA1-Hash des entsprechenden Commits. Dies ist nur gegeben, wenn die Option -c , -C oder --amend angegeben wurde.

Ähnlich wie beim pre-commit bricht das Beenden mit einem Nicht-Null-Status das Commit ab.

Pre-Rebase

Dieser Hook wird aufgerufen, bevor git rebase zu ändern beginnt. Dieser Haken wird normalerweise verwendet, um sicherzustellen, dass eine Rebase-Operation geeignet ist.

Dieser Haken benötigt 2 Parameter:

1. der vorgelagerte Zweig, aus dem die Serie gegliedert wurde, und
2. der Zweig wird umbasiert (leer, wenn der aktuelle Zweig umbasiert wird).

Sie können den Rebase-Vorgang abbrechen, indem Sie den Status ungleich Null beenden.

Vor dem Empfang

Dieser Hook wird jedes Mal ausgeführt, wenn jemand git push , um Commits in das Repository zu verschieben. Es befindet sich immer im Remote-Repository, das das Ziel des Push ist, und nicht im ursprünglichen (lokalen) Repository.

Der Hook wird ausgeführt, bevor Referenzen aktualisiert werden. Sie wird normalerweise verwendet, um jegliche Art von Entwicklungsrichtlinien durchzusetzen.

Das Skript nimmt keine Parameter an, aber jeder übergebene Ref wird in einer separaten Zeile bei der Standardeingabe im folgenden Format an das Skript übergeben:

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

Aktualisieren

Dieser Hook wird nach dem pre-receive aufgerufen und funktioniert genauso. Es wird aufgerufen, bevor alles aktualisiert wird, aber es wird separat für jeden Ref aufgerufen, der verschoben wurde, und nicht für alle Refs gleichzeitig.

Dieser Haken akzeptiert die folgenden 3 Argumente:

• Name des Refs, der aktualisiert wird,
• alter Objektname in der Referenz gespeichert, und
• Neuer Objektname in der Referenz gespeichert.

Dies ist die gleiche Information, die an pre-receive wird. Da jedoch die update für jeden Ref einzeln aufgerufen wird, können Sie einige Refs ablehnen und andere zulassen.

Pre-Push

Verfügbar in Git 1.8.2 und höher.

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

Stellen Sie sicher, dass das Maven-Build (oder ein anderes Build-System) vor dem Festschreiben ausgeführt wird

.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

Bestimmte Push-Vorgänge automatisch an andere Repositorys weiterleiten

post-receive Hooks können verwendet werden, um eingehende Pushs automatisch an ein anderes Repository weiterzuleiten.

$ 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

In diesem Beispiel sucht der egrep regexp nach einem bestimmten Zweigformat (hier: JIRA-12345, um Jira-Probleme zu benennen). Sie können diesen Teil ausschalten, wenn Sie natürlich alle Zweige weiterleiten möchten.