Zoeken…


Syntaxis

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

Opmerkingen

--no-verify of -n om alle lokale hooks op het gegeven git commando over te slaan.
Bijv .: git commit -n

Informatie op deze pagina is verzameld van de officiële Git-documenten en Atlassian .

Commit-msg

Deze hook lijkt op de hook prepare-commit-msg , maar wordt genoemd nadat de gebruiker een commit-bericht invoert in plaats van ervoor. Dit wordt meestal gebruikt om ontwikkelaars te waarschuwen als hun commit-bericht een onjuist formaat heeft.

Het enige argument dat aan deze haak wordt doorgegeven, is de naam van het bestand dat het bericht bevat. Als je het bericht dat de gebruiker heeft ingevoerd niet leuk vindt, kun je dit bestand ter plekke wijzigen (hetzelfde als prepare-commit-msg ) of je kunt de commit volledig afbreken door te verlaten met een niet-nul status.

Het volgende voorbeeld wordt gebruikt om te controleren of het woordticket gevolgd door een nummer aanwezig is in het commit-bericht

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 zijn alleen van invloed op de lokale repositories waarin ze zich bevinden. Elke ontwikkelaar kan zijn eigen lokale hooks wijzigen, zodat ze niet betrouwbaar kunnen worden gebruikt als een manier om een commit-beleid af te dwingen. Ze zijn ontworpen om het voor ontwikkelaars gemakkelijker te maken zich aan bepaalde richtlijnen te houden en potentiële problemen onderweg te voorkomen.

Er zijn zes soorten lokale hooks: pre-commit, prepare-commit-msg, commit-msg, post-commit, post-checkout en pre-rebase.

De eerste vier hooks hebben betrekking op commits en stellen je in staat om controle te hebben over elk onderdeel in de levenscyclus van een commit. Met de laatste twee kun je wat extra acties of veiligheidscontroles uitvoeren voor de git checkout en git rebase commando's.

Met alle "pre-" hooks kunt u de actie wijzigen die gaat plaatsvinden, terwijl de "post-" hooks voornamelijk worden gebruikt voor meldingen.

Post-checkout

Deze hook werkt op dezelfde manier als de post-commit hook, maar deze wordt aangeroepen wanneer je een referentie met git checkout . Dit kan een handig hulpmiddel zijn voor het opruimen van uw werkmap met automatisch gegenereerde bestanden die anders verwarring zouden veroorzaken.

Deze haak accepteert drie parameters:

  1. de ref van de vorige HEAD,
  2. de ref van de nieuwe HEAD, en
  3. een vlag die aangeeft of het een filiaalafrekening of een bestandsafrekening was (respectievelijk 1 of 0 ).

De exit status heeft geen invloed op het git checkout commando.

Post-commit

Deze hook wordt direct na de commit-msg hook aangeroepen. Het kan de uitkomst van de git commit bewerking niet veranderen, daarom wordt het voornamelijk gebruikt voor kennisgevingsdoeleinden.

Het script heeft geen parameters en de exitstatus heeft op geen enkele manier invloed op de commit.

Post-ontvangen

Deze haak wordt genoemd na een succesvolle duwbewerking. Het wordt meestal gebruikt voor kennisgevingsdoeleinden.

Het script heeft geen parameters, maar pre-receive dezelfde informatie als pre-receive via standaardinvoer:

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

Pre-commit

Deze hook wordt elke keer uitgevoerd als je git commit uitvoert, om te verifiëren wat er gaat gebeuren. U kunt deze haak gebruiken om de momentopname te inspecteren die op het punt staat te worden vastgelegd.

Dit type hook is handig voor het uitvoeren van geautomatiseerde tests om ervoor te zorgen dat de inkomende commit de bestaande functionaliteit van uw project niet breekt. Dit type hook kan ook controleren op witruimte- of EOL-fouten.

Er worden geen argumenten doorgegeven aan het pre-commit script, en afsluiten met een niet-nul status breekt de hele commit af.

Bereid-commit-msg

Deze hook wordt genoemd naar de pre-commit hook om de teksteditor te vullen met een commit-bericht. Dit wordt meestal gebruikt om de automatisch gegenereerde commit-berichten voor geplette of samengevoegde commits te wijzigen.

Een tot drie argumenten worden aan deze haak doorgegeven:

  • De naam van een tijdelijk bestand dat het bericht bevat.
  • Het type commit ook
    • bericht ( -m of -F optie),
    • sjabloon ( -t optie),
    • merge (als het een merge commit is), of
    • squash (als het andere commits verplettert).
  • De SHA1-hash van de betreffende commit. Dit wordt alleen gegeven als de optie -c , -C of --amend is opgegeven.

Net als bij pre-commit , wordt bij het afsluiten met een niet-nulstatus de commit afgebroken.

Pre-rebase

Deze hook wordt aangeroepen voordat git rebase begint te veranderen. Deze haak wordt meestal gebruikt om ervoor te zorgen dat een rebase-bewerking geschikt is.

Deze haak heeft 2 parameters:

  1. de stroomopwaartse tak waaruit de serie werd gevorkt, en
  2. de branch wordt rebased (leeg bij het rebasen van de huidige branch).

U kunt de rebase-bewerking afbreken door af te sluiten met een niet-nul status.

Pre-receive

Deze hook wordt elke keer uitgevoerd als iemand git push gebruikt om commits naar de repository te pushen. Het bevindt zich altijd in de externe repository die de bestemming van de push is en niet in de oorspronkelijke (lokale) repository.

De hook wordt uitgevoerd voordat referenties worden bijgewerkt. Het wordt meestal gebruikt om elke vorm van ontwikkelingsbeleid af te dwingen.

Het script heeft geen parameters, maar elke ref die wordt gepusht, wordt doorgegeven aan het script op een aparte regel bij standaardinvoer in het volgende formaat:

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

Bijwerken

Deze haak wordt genoemd naar pre-receive en werkt op dezelfde manier. Het wordt aangeroepen voordat iets daadwerkelijk wordt bijgewerkt, maar wordt afzonderlijk aangeroepen voor elke ref die werd gepusht in plaats van alle refs tegelijk.

Deze haak accepteert de volgende 3 argumenten:

  • naam van de ref die wordt bijgewerkt,
  • oude objectnaam opgeslagen in de ref, en
  • nieuwe objectnaam opgeslagen in de ref.

Dit is dezelfde informatie die wordt doorgegeven om pre-receive , maar omdat update voor elke ref afzonderlijk wordt aangeroepen, kunt u sommige refs afwijzen terwijl u andere toestaat.

Pre-push

Beschikbaar in Git 1.8.2 en hoger.

1.8

Pre-push haken kunnen worden gebruikt om te voorkomen dat een push gaat. Redenen waarom dit nuttig is, zijn onder meer: het blokkeren van onbedoelde handmatige pushs naar specifieke vertakkingen, of het blokkeren van pushs als een vastgestelde controle mislukt (unit tests, syntaxis).

Een pre-push hook wordt gemaakt door eenvoudig een bestand met de naam pre-push onder .git/hooks/ , en ( gotcha alert ), en zorg ervoor dat het bestand uitvoerbaar is: chmod +x ./git/hooks/pre-push .

Hier is een voorbeeld van Hannah Wolfe dat een push om te beheersen blokkeert:

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

Hier is een voorbeeld van Volkan Unsal dat ervoor zorgt dat RSpec-tests slagen voordat de push wordt toegestaan:

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

Zoals je kunt zien, zijn er veel mogelijkheden, maar het belangrijkste is om exit 0 te exit 0 als er goede dingen zijn gebeurd en exit 1 als er slechte dingen zijn gebeurd. Telkens wanneer je exit 1 de push voorkomen en heeft je code de status van voordat je git push... uitvoert git push...

Houd er bij het gebruik van client-side hooks rekening mee dat gebruikers alle client-side hooks kunnen overslaan door de optie "--no-verifieer" te gebruiken bij een push. Als u op de haak vertrouwt om het proces af te dwingen, kunt u zich branden.

Documentatie: https://git-scm.com/docs/githooks#_pre_push
Officieel voorbeeld: https://github.com/git/git/blob/87c86dd14abe8db7d00b0df5661ef8cf147a72a3/templates/hooks--pre-push.sample

Controleer de Maven-build (of ander build-systeem) voordat u begint

.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

Bepaalde pushes automatisch doorsturen naar andere repositories

post-receive hooks kunnen worden gebruikt om inkomende pushes automatisch door te sturen naar een andere repository.

$ 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 dit voorbeeld zoekt de egrep regexp naar een specifiek vertakkingsformaat (hier: JIRA-12345 zoals gebruikt om Jira-problemen te benoemen). Je kunt dit onderdeel natuurlijk verlaten als je alle takken wilt doorsturen.



Modified text is an extract of the original Stack Overflow Documentation
Licentie onder CC BY-SA 3.0
Niet aangesloten bij Stack Overflow