Git
krokar

Syntax

• .git / krokar / applypatch-msg
• .git / krokar / commit-msg
• .git / krokar / postuppdatering
• .git / krokar / pre-applypatch
• .git / krokar / pre-commit
• .git / krokar / förbereda-commit-msg
• .git / krokar / pre-tryck
• .git / krokar / pre-omviktningen
• .git / krokar / uppdatering

Anmärkningar

Commit-msg

Den här kroken liknar haken prepare-commit-msg , men den kallas efter att användaren har skrivit in ett meddelande snarare än tidigare. Detta används vanligen för att varna utvecklare om deras engagemang är i fel format.

Det enda argumentet som skickas till denna krok är namnet på filen som innehåller meddelandet. Om du inte gillar meddelandet som användaren har angett kan du antingen ändra den här filen på plats (samma som prepare-commit-msg ) eller så kan du avbryta åtagandet helt genom att avsluta med en status som inte är noll.

Följande exempel används för att kontrollera om ordet biljett följt av ett nummer finns i åtagandemeddelandet

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

Lokala krokar

Lokala krokar påverkar endast de lokala förvar där de bor. Varje utvecklare kan ändra sina egna lokala krokar, så att de inte kan användas på ett tillförlitligt sätt som ett sätt att verkställa en åtagandepolicy. De är utformade för att göra det lättare för utvecklare att följa vissa riktlinjer och undvika potentiella problem på vägen.

Det finns sex typer av lokala krokar: pre-commit, Prepar-commit-msg, commit-msg, post-commit, post-checkout och pre-rebase.

De första fyra krokarna hänför sig till åtaganden och gör att du kan ha viss kontroll över varje del i en engagements livscykel. De sista två låter dig utföra några extra åtgärder eller säkerhetskontroller för git-kassan och git-rebasskommandon.

Alla "pre-" krokar låter dig ändra den åtgärd som håller på att ske, medan "post-" krokarna används främst för aviseringar.

Post-kassan

Den här kroken fungerar på samma sätt som den post-commit kroken, men den heter när du lyckas kolla in en referens med git checkout . Detta kan vara ett användbart verktyg för att rensa din arbetskatalog med auto-genererade filer som annars skulle orsaka förvirring.

Denna krok accepterar tre parametrar:

1. domaren från föregående HEAD,
2. domaren för den nya HEAD, och
3. en flagga som indikerar om det var en grenutcheckning eller en filutcheckning ( 1 respektive 0 ).

Dess utgångsstatus påverkar inte kommandot git checkout .

Post-begå

Denna krok kallas omedelbart efter commit-msg kroken. Det kan inte ändra resultatet av git commit , därför används den främst för anmälningsändamål.

Skriptet tar inga parametrar och dess utgångsstatus påverkar inte engagemanget på något sätt.

Post-får

Denna krok kallas efter en framgångsrik pushoperation. Det används vanligtvis för anmälningsändamål.

Skriptet tar inga parametrar, men skickas samma information som pre-receive via standardinmatning:

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

Pre-begå

Denna krok körs varje gång du kör git commit att verifiera vad som håller på att begås. Du kan använda den här kroken för att inspektera ögonblicksbilden som håller på att begås.

Den här typen av krok är användbar för att köra automatiska test för att se till att den inkommande åtaganden inte bryter med befintligt funktionalitet i ditt projekt. Denna typ av krok kan också kontrollera om det finns fel i fel eller EOL.

Inga argument överförs till pre-commit-skriptet och avslutande med status som inte har noll avbryter hela commit.

Förbered-commit-msg

Denna krok kallas efter pre-commit kroken för att fylla textredigeraren med ett commit-meddelande. Detta används vanligtvis för att ändra de automatiskt genererade åtkomstmeddelandena för klämda eller sammanslagna åtaganden.

Ett till tre argument överförs till denna krok:

• Namnet på en tillfällig fil som innehåller meddelandet.
• Antingen engagera, antingen
  • meddelande ( -m eller -F alternativ),
  • mall ( -t alternativ),
  • sammanslagning (om det är en fusionsåtagande), eller
  • squash (om det är squashing andra åtaganden).
• SHA1-hash för relevant åtagande. Detta ges endast om alternativet -c , -C eller - --amend har givits.

I likhet med pre-commit , spännande med en icke-noll status avbryter begå.

Pre-omviktningen

Denna krok kallas innan git rebase börjar ändra kodstrukturen. Den här kroken används vanligtvis för att se till att en rebasoperation är lämplig.

Denna krok tar två parametrar:

1. uppströmsgrenen som serien gick från, och
2. grenen återfas (tom när du återfasar nuvarande gren).

Du kan avbryta omfasningsoperationen genom att avsluta med en status som inte är noll.

Pre-motta

Den här kroken körs varje gång någon använder git push att skjuta kommit till förvaret. Den ligger alltid i fjärrförvaret som är pushens destination och inte i det ursprungliga (lokala) förvaret.

Kroken går innan referenser uppdateras. Det används vanligtvis för att verkställa någon form av utvecklingspolitik.

Skriptet tar inga parametrar, men varje ref som skjuts överförs till skriptet på en separat rad på standardinmatning i följande format:

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

Uppdatering

Denna krok kallas efter pre-receive , och den fungerar på samma sätt. Det kallas innan någonting faktiskt uppdateras, men kallas separat för varje ref som sköt i stället för alla refs på en gång.

Denna krok accepterar följande tre argument:

• namnet på domaren som uppdateras,
• gammalt objektnamn lagrat i ref, och
• nytt objektnamn lagrat i ref.

Det här är samma information som skickas för att pre-receive , men eftersom update åberopas separat för varje ref, kan du avvisa vissa refs medan du tillåter andra.

Pre-tryck

Finns i Git 1.8.2 och högre .

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

Verifiera Maven build (eller annat build-system) innan du gör det

.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

Vidarebefordra automatiskt vissa tryck till andra förvar

krokar post-receive kan användas för att automatiskt vidarebefordra inkommande tryck till ett annat arkiv.

$ 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

I det här exemplet egrep regexp efter ett specifikt grenformat (här: JIRA-12345 som används för att namnge Jira-problem). Du kan lämna den här delen om du naturligtvis vill vidarebefordra alla grenar.