Git
Haki

Składnia

• .git / hooks / applypatch-msg
• .git / hooks / commit-msg
• .git / hooks / post-update
• .git / hooks / pre-applypatch
• .git / hooks / pre-commit
• .git / hooks / Preparation-commit-msg
• .git / hooks / pre-push
• .git / hooks / pre-rebase
• .git / hooks / update

Uwagi

Commit-msg

Ten haczyk jest podobny do haka prepare-commit-msg , ale jest wywoływany, gdy użytkownik wprowadzi komunikat zatwierdzenia, a nie wcześniej. Jest to zwykle używane do ostrzegania programistów, jeśli ich komunikat zatwierdzenia ma niepoprawny format.

Jedynym argumentem przekazanym do tego hooka jest nazwa pliku zawierającego komunikat. Jeśli nie podoba ci się komunikat, który wprowadził użytkownik, możesz albo zmienić ten plik w miejscu (tak samo jak prepare-commit-msg ), lub możesz całkowicie przerwać zatwierdzenie, wychodząc ze stanu niezerowego.

Poniższy przykład służy do sprawdzenia, czy w komunikacie zatwierdzenia znajduje się słowo bilet, po którym następuje liczba

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

Lokalne haki

Lokalne zaczepy wpływają tylko na lokalne repozytoria, w których się znajdują. Każdy programista może zmieniać własne lokalne zaczepy, więc nie można ich używać niezawodnie jako sposobu egzekwowania zasad zatwierdzania. Zostały zaprojektowane tak, aby ułatwić programistom przestrzeganie określonych wytycznych i unikanie potencjalnych problemów w przyszłości.

Istnieje sześć rodzajów lokalnych przechwyceń: wstępne zatwierdzenie, przygotowanie-zatwierdzenie-msg, zatwierdzenie-msg, po zatwierdzeniu, po pobraniu i przedrebase.

Pierwsze cztery haczyki odnoszą się do zatwierdzeń i pozwalają ci mieć kontrolę nad każdą częścią w cyklu życia zatwierdzenia. Ostatnie dwa pozwalają wykonać dodatkowe czynności lub kontrole bezpieczeństwa dla poleceń git checkout i git rebase.

Wszystkie zaczepy „przed” umożliwiają zmianę działania, które ma się odbyć, a zaczepy „po” służą przede wszystkim do powiadomień.

Kasa po zakończeniu transakcji

Ten hak działa podobnie do haka post-commit , ale jest wywoływany za każdym razem, gdy pomyślnie sprawdzasz referencję za pomocą git checkout . Może to być przydatne narzędzie do czyszczenia katalogu roboczego z automatycznie generowanych plików, które w przeciwnym razie spowodowałyby zamieszanie.

Ten hak akceptuje trzy parametry:

1. ref. poprzedniej HEAD,
2. ref nowego HEAD, oraz
3. flaga wskazująca, czy była to gałąź lub gałąź pliku (odpowiednio 1 lub 0 ).

Status wyjścia nie ma wpływu na polecenie git checkout .

Po zatwierdzeniu

Ten hak jest wywoływany natychmiast po haku commit-msg . Nie może zmienić wyniku operacji git commit , dlatego jest używany głównie do celów powiadomień.

Skrypt nie przyjmuje parametrów, a jego status wyjścia w żaden sposób nie wpływa na zatwierdzenie.

Po otrzymaniu

Ten hak jest wywoływany po udanej operacji pchania. Jest zwykle używany do celów powiadomień.

Skrypt nie przyjmuje parametrów, ale jest wysyłany te same informacje, co pre-receive za pośrednictwem standardowego wejścia:

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

Wstępnie zatwierdzić

Ten zaczep jest wykonywany za każdym razem, gdy uruchamiasz git commit , aby sprawdzić, co ma zostać git commit . Możesz użyć tego haka, aby sprawdzić migawkę, która ma zostać zatwierdzona.

Ten rodzaj przechwytywania jest przydatny do uruchamiania automatycznych testów, aby upewnić się, że przychodzące zatwierdzenie nie psuje istniejącej funkcjonalności twojego projektu. Ten typ haka może również sprawdzać, czy występują spacje lub błędy EOL.

Do skryptu poprzedzającego zatwierdzenie nie są przekazywane żadne argumenty, a wychodzenie ze statusem niezerowym przerywa całe zatwierdzenie.

Przygotuj-zatwierdzenie-msg

Ten hak jest wywoływany po haku pre-commit aby wypełnić edytor tekstowy komunikatem zatwierdzenia. Jest to zwykle używane do zmiany automatycznie generowanych komunikatów zatwierdzania dla zgniecionych lub scalonych zatwierdzeń.

Do tego haka przekazywane są od jednego do trzech argumentów:

• Nazwa pliku tymczasowego zawierającego wiadomość.
• Rodzaj zatwierdzenia też
  • wiadomość (opcja -m lub -F ),
  • szablon (opcja -t ),
  • scalanie (jeśli jest to zatwierdzanie scalania) lub
  • squash (jeśli zgniata inne zatwierdzenia).
• Skrót SHA1 odpowiedniego zatwierdzenia. Jest to podawane tylko wtedy, gdy --amend opcję -c , -C lub --amend .

Podobne do pre-commit , wyjście ze statusem niezerowym przerywa zatwierdzenie.

Pre-rebase

Ten hak jest wywoływany, zanim git rebase zacznie zmieniać strukturę kodu. Ten zaczep jest zwykle używany do upewnienia się, że operacja zmiany bazy jest odpowiednia.

Ten hak przyjmuje 2 parametry:

1. odgałęzienie, z którego rozwidlono serię, oraz
2. gałąź jest ponownie bazowana (pusta przy ponownej publikacji obecnej gałęzi).

Możesz przerwać operację bazowania, wychodząc ze stanu niezerowego.

Odbierz wcześniej

Ten zaczep jest wykonywany za każdym razem, gdy ktoś używa polecenia git push do wypychania zatwierdzeń do repozytorium. Zawsze znajduje się w zdalnym repozytorium, które jest celem wypychania, a nie w źródłowym (lokalnym) repozytorium.

Hak działa przed aktualizacją jakichkolwiek odniesień. Zwykle służy do egzekwowania dowolnego rodzaju polityki rozwoju.

Skrypt nie przyjmuje parametrów, ale każde wysyłane odwołanie jest przekazywane do skryptu w osobnym wierszu na standardowym wejściu w następującym formacie:

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

Aktualizacja

Ten hak jest wywoływany po pre-receive i działa w ten sam sposób. Jest wywoływany, zanim cokolwiek zostanie zaktualizowane, ale jest wywoływany osobno dla każdego odsuniętego odwołania, a nie dla wszystkich poleceń naraz.

Ten hak przyjmuje następujące 3 argumenty:

• nazwa aktualizowanej referencji,
• stara nazwa obiektu zapisana w referencji, oraz
• nowa nazwa obiektu zapisana w ref.

Są to te same informacje, które są przekazywane do pre-receive , ale ponieważ update jest wywoływana osobno dla każdego odwołania, możesz odrzucić niektóre odwołania, jednocześnie pozwalając innym.

Pre-push

Dostępne w Git 1.8.2 i nowszych.

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

Sprawdź kompilację Maven (lub inny system kompilacji) przed zatwierdzeniem

.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

Automatyczne przekazywanie niektórych wypychań do innych repozytoriów

haczyki post-receive mogą służyć do automatycznego przekazywania przychodzących wypychań do innego repozytorium.

$ 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

W tym przykładzie egrep regularne egrep szuka określonego formatu gałęzi (tutaj: JIRA-12345 jako nazwa problemów Jira). Oczywiście możesz pominąć tę część, jeśli chcesz przekazać wszystkie gałęzie.