8.3 Customizing Git - Git-hake (Git Hooks)

Die eerste vier hake het te make met die vasleggingsproses.

Die pre-commit haak word eerste uitgevoer, selfs voordat jy 'n vasleggingsboodskap intik. Dit word gebruik om die momentopname (snapshot) te inspekteer wat op die punt staan om vasgelê te word, om te sien of jy iets vergeet het, om seker te maak toetse loop, of om te ondersoek wat jy ook al in die kode moet inspekteer. As dit nie-nul uitstaan (exiting non-zero) van hierdie haak, word die vaslegging gestaak, al kan jy dit omseil met git commit --no-verify. Jy kan dinge doen soos om te kyk vir kodestyl (voer lint of iets ekwivalents uit), kyk vir agtereenvolgende witruimte (die verstellingshaak doen presies dit), of kyk vir gepaste dokumentasie oor nuwe metodes.

Die prepare-commit-msg haak word uitgevoer voordat die vasleggingsboodskap-redigeerder aangeskakel word, maar nadat die verstekboodskap geskep is. Dit laat jou toe om die verstekboodskap te redigeer voordat die vasleggingsouteur dit sien. Hierdie haak neem 'n paar parameters: die pad na die lêer wat die vasleggingsboodskap tot dusver hou, die tipe vaslegging, en die vaslegging SHA-1 as dit 'n geamendeerde (amended) vaslegging is. Hierdie haak is oor die algemeen nie nuttig vir normale vasleggings nie; dit is eerder goed vir vasleggings waar die verstekboodskap outomaties gegenereer word, soos sjabloon-vasleggingsboodskappe, saamsmeltingsvasleggings (merge commits), saamgeperste vasleggings (squashed commits), en geamendeerde vasleggings. Jy kan dit gebruik in samehang met 'n vasleggingsjabloon om programmaties inligting in te voeg.

Die commit-msg haak neem een parameter, wat weer die pad is na 'n tydelike lêer wat die vasleggingsboodskap bevat wat deur die ontwikkelaar geskryf is. As hierdie skrip nie-nul uitstaan, staak Git die vasleggingsproses, sodat jy dit kan gebruik om jou projektoestand of vasleggingsboodskap te valideer voordat jy toelaat dat 'n vaslegging deurgaan. In die laaste afdeling van hierdie hoofstuk sal ons demonstreer hoe om hierdie haak te gebruik om te kyk dat jou vasleggingsboodskap aan 'n vereiste patroon voldoen.

Nadat die hele vasleggingsproses voltooi is, loop die post-commit haak. Dit neem geen parameters nie, maar jy kan maklik die laaste vaslegging kry deur git log -1 HEAD uit te voer. Oor die algemeen word hierdie skrip gebruik vir kennisgewing of iets soortgelyks.

Jy kan drie kliëntkant-hake opstel vir 'n e-posgebaseerde werkvloei. Hulle word almal opgeroep deur die git am opdrag, so as jy nie daardie opdrag in jou werkvloei gebruik nie, kan jy veilig na die volgende afdeling oorslaan. As jy pleisters (patches) oor e-pos aanvaar wat deur git format-patch voorberei is, dan kan sommige hiervan vir jou nuttig wees.

Die eerste haak wat uitgevoer word, is applypatch-msg. Dit neem 'n enkele argument: die naam van die tydelike lêer wat die voorgestelde vasleggingsboodskap bevat. Git staak die pleister as hierdie skrip nie-nul uitstaan. Jy kan dit gebruik om seker te maak dat 'n vasleggingsboodskap behoorlik geformatteer is, of om die boodskap te normaliseer deur te hê dat die skrip dit ter plaatse redigeer.

Die volgende haak om te loop wanneer pleisters via git am toegepas word, is pre-applypatch. Taamlik verwarrend word dit uitgevoer nadat die pleister toegepas is, maar voordat 'n vaslegging gemaak word, sodat jy dit kan gebruik om die momentopname te inspekteer voordat jy die vaslegging maak. Jy kan toetse uitvoer of andersins die werkboom (working tree) met hierdie skrip inspekteer. As iets ontbreek of die toetse nie slaag nie, staak die uitstaan van nie-nul die git am skrip sonder om die pleister vas te lê.

Die laaste haak om te loop tydens 'n git am bewerking is post-applypatch, wat loop nadat die vaslegging gemaak is. Jy kan dit gebruik om 'n groep of die outeur van die pleister wat jy ingetrek het te ken te gee dat jy dit gedoen het. Jy kan nie die pleisterproses met hierdie skrip stop nie.

Die pre-rebase haak loop voordat jy enigiets rebase en kan die proses tot 'n stilstand bring deur nie-nul uit te staan. Jy kan hierdie haak gebruik om te verbied om enige vasleggings te rebase wat reeds gepush is. Die voorbeeld pre-rebase haak wat Git installeer, doen dit, hoewel dit sekere aannames maak wat dalk nie ooreenstem met jou werkvloei nie.

Die post-rewrite haak word uitgevoer deur opdragte wat vasleggings vervang, soos git commit --amend en git rebase (hoewel nie deur git filter-branch nie). Sy enkele argument is watter opdrag die herskrywing geaktiveer het, en dit ontvang 'n lys van herskrywings op stdin. Hierdie haak het baie van dieselfde gebruike as die post-checkout en post-merge hake.

Nadat jy 'n suksesvolle git checkout uitgevoer het, loop die post-checkout haak; jy kan dit gebruik om jou werkgids behoorlik op te stel vir jou projekomgewing. Dit kan beteken dat groot binêre lêers ingebring word wat jy nie onder weergawebeheer wil hê nie, dokumentasie outomaties gegenereer word, of iets langs daardie lyne.

Die post-merge haak loop na 'n suksesvolle merge opdrag. Jy kan dit gebruik om data in die werkboom te herstel wat Git nie kan naspoor nie, soos toegangsregte (permissions) data. Hierdie haak kan eweneens die teenwoordigheid valideer van lêers ekstern aan Git-beheer wat jy dalk wil hê ingekopieer moet word wanneer die werkboom verander.

Die pre-push haak loop tydens git push, nadat die afgeleë verwysings (remote refs) opgedateer is, maar voordat enige objekte oorgedra is. Dit ontvang die naam en ligging van die remote as parameters, en 'n lys van te-word-opgedateerde verwysings deur stdin. Jy kan dit gebruik om 'n stel verwysingsopdaterings te valideer voordat 'n push plaasvind ('n nie-nul uitgangskode sal die push staak).

Git doen afvalinsameling (garbage collection) van tyd tot tyd as deel van sy normale werking deur git gc --auto op te roep. Die pre-auto-gc haak word opgeroep net voordat die afvalinsameling plaasvind, en kan gebruik word om jou te ken te gee dat dit gebeur, of om die insameling te staak as nou nie 'n goeie tyd is nie.

Die eerste skrip om te loop wanneer 'n push van 'n kliënt gehanteer word, is pre-receive. Dit neem 'n lys van verwysings wat vanaf stdin gepush word; as dit nie-nul uitstaan, word nie een van hulle aanvaar nie. Jy kan hierdie haak gebruik om dinge te doen soos om seker te maak geen van die opgedateerde verwysings is nie-vinnig-voorwaarts (non-fast-forwards) nie, of om toegangsbeheer te doen vir al die verwysings en lêers wat hulle met die push wysig.

Die update skrip is baie soos die pre-receive skrip, behalwe dat dit een keer loop vir elke tak wat die stootder (pusher) probeer opdateer. As die stootder probeer om na veelvuldige takke te push, loop pre-receive slegs een keer, terwyl update een keer loop per tak waarna hulle push. In plaas van om van stdin te lees, neem hierdie skrip drie argumente: die naam van die verwysing (tak), die SHA-1 waarna daardie verwysing voor die push gewys het, en die SHA-1 wat die gebruiker probeer push. As die update skrip nie-nul uitstaan, word slegs daardie verwysing geweier; ander verwysings kan steeds opgedateer word.

Die post-receive haak loop nadat die hele proses voltooi is en kan gebruik word om ander dienste op te dateer of gebruikers in kennis te stel. Dit neem dieselfde stdin-data as die pre-receive haak. Voorbeelden sluit in om 'n lys te e-pos, 'n deurlopende integrasie-bediener (continuous integration server) in kennis te stel, of om 'n kaartjie-opsporingstelsel (ticket-tracking system) op te dateer – jy kan selfs die vasleggingsboodskappe ontleed om te kyk of enige kaartjies geopen, gewysig of gesluit moet word. Hierdie skrip kan nie die push-proses stop nie, maar die kliënt ontkoppel nie voordat dit voltooi is nie, so wees versigtig as jy iets probeer doen wat lank kan neem.