8.3 Anpassa Git - Git‑krokar

De första fyra hooksen har att göra med incheckningsprocessen.

Kroken pre-commit körs först, innan du ens skriver in ett incheckningsmeddelande. Den används för att inspektera ögonblicksbilden som ska checkas in, för att se om du glömt något, för att se till att tester körs, eller för att granska det du behöver i koden. Om skriptet avslutas med en icke‑nollkod avbryts incheckningen, även om du kan förbigå den med git commit --no-verify. Du kan till exempel kontrollera kodstil (köra lint eller motsvarande), kontrollera släpande blanktecken (standardkroken gör exakt detta) eller kontrollera att nya metoder har korrekt dokumentation.

Kroken prepare-commit-msg körs innan redigeraren för incheckningsmeddelandet startar men efter att standardmeddelandet skapats. Den låter dig redigera standardmeddelandet innan författaren ser det. Kroken tar några parametrar: sökvägen till filen som innehåller incheckningsmeddelandet hittills, typen av incheckning och incheckningens SHA‑1 om det gäller en ändrad incheckning. Denna krok är i allmänhet inte användbar för normala incheckningar; snarare är den bra för incheckningar där standardmeddelandet genereras automatiskt, såsom mallade incheckningsmeddelanden, sammanslagningsincheckningar, sammanfogade incheckningar och ändrade incheckningar. Du kan använda den tillsammans med en incheckningsmall för att programatiskt infoga information.

Kroken commit-msg tar en parameter, vilket återigen är sökvägen till en temporär fil som innehåller incheckningsmeddelandet som utvecklaren har skrivit. Om detta skript avslutas med en icke‑nollkod avbryter Git incheckningsprocessen, så du kan använda det för att validera projektets läge eller incheckningsmeddelandet innan incheckningen får gå igenom. I sista delen av det här kapitlet visar vi hur du använder denna krok för att kontrollera att incheckningsmeddelandet följer ett obligatoriskt mönster.

När hela incheckningsprocessen är klar körs kroken post-commit. Den tar inga parametrar, men du kan enkelt få den senaste incheckningen genom att köra git log -1 HEAD. I allmänhet används detta skript för aviseringar eller liknande.

Du kan sätta upp tre krokar på klientsidan för ett e‑postbaserat arbetsflöde. De anropas alla av kommandot git am, så om du inte använder det kommandot i ditt arbetsflöde kan du tryggt hoppa till nästa avsnitt. Om du tar emot ändringspatchar via e‑post som förberetts av git format-patch kan några av dessa vara användbara.

Den första kroken som körs är applypatch-msg. Den tar ett enda argument: namnet på den temporära filen som innehåller det föreslagna incheckningsmeddelandet. Git avbryter ändringspatchen om skriptet avslutas med en icke‑nollkod. Du kan använda detta för att se till att ett incheckningsmeddelande är korrekt formaterat, eller för att normalisera meddelandet genom att låta skriptet redigera det på plats.

Nästa krok som körs när man applicerar ändringspatchar via git am är pre-applypatch. Lite förvirrande körs den efter att ändringspatchen applicerats men före att en incheckning görs, så du kan använda den för att inspektera ögonblicksbilden innan incheckningen sker. Du kan köra tester eller på annat sätt granska arbetsträdet med detta skript. Om något saknas eller testerna inte går igenom avbryter en icke‑nollkod git am‑skriptet utan att checka in ändringspatchen.

Den sista kroken som körs under en git am‑operation är post-applypatch, som körs efter att incheckningen har gjorts. Du kan använda den för att meddela en grupp eller författaren till ändringspatchen att du har tagit in den. Du kan inte stoppa själva appliceringen med detta skript.

Kroken pre-rebase körs innan du ombaserar något och kan stoppa processen genom att avslutas med en icke‑nollkod. Du kan använda denna krok för att förhindra ombasering av incheckningar som redan har skickats upp. Exempelkroken pre-rebase som Git installerar gör detta, även om den gör vissa antaganden som kanske inte matchar ditt arbetsflöde.

Kroken post-rewrite körs av kommandon som ersätter incheckningar, såsom git commit --amend och git rebase (men inte av git filter-branch). Dess enda argument är vilket kommando som utlöste omskrivningen, och den tar emot en lista över omskrivningar på stdin. Denna krok har många av samma användningar som hooksen post-checkout och post-merge.

Efter att du har kört en lyckad git checkout körs kroken post-checkout; du kan använda den för att ställa in din arbetskatalog korrekt för projektets miljö. Det kan innebära att flytta in stora binärfiler som du inte vill versionshantera, auto‑generera dokumentation eller något i den stilen.

Kroken post-merge körs efter en lyckad merge. Du kan använda den för att återställa data i arbetsträdet som Git inte kan spåra, såsom behörighetsdata. Kroken kan också validera att filer som ligger utanför Gits kontroll finns på plats, sådant du vill kopiera in när arbetsträdet förändras.

Kroken pre-push körs under git push, efter att fjärrreferenserna uppdaterats men innan några objekt har överförts. Den tar namnet och platsen för fjärrkodförrådet som parametrar, samt en lista över referenser som ska uppdateras via stdin. Du kan använda den för att validera uppsättningen referensuppdateringar innan en uppskickning sker (en icke‑nollkod avbryter uppskickningen).

Git gör ibland skräpsamling som en del av sin normala drift, genom att anropa git gc --auto. Kroken pre-auto-gc anropas precis innan skräpsamlingen sker, och kan användas för att meddela dig att detta händer, eller för att avbryta samlingen om det inte är ett bra tillfälle.

Det första skriptet som körs när en uppskickning tas emot från en klient är pre-receive. Det tar en lista över referenser som skickas upp via stdin; om det avslutas med en icke‑nollkod accepteras ingen av dem. Du kan använda denna krok för att till exempel se till att inga uppdaterade referenser är icke‑snabbspolningar, eller för att göra åtkomstkontroll för alla referenser och filer de ändrar med uppskickningen.

Skriptet update är mycket likt skriptet pre-receive, förutom att det körs en gång för varje gren som den som skickar upp försöker uppdatera. Om någon försöker skicka till flera grenar körs pre-receive bara en gång, medan update körs en gång per gren de skickar upp till. I stället för att läsa från stdin tar skriptet tre argument: namnet på referensen (grenen), SHA‑1‑värdet som referensen pekade på före uppskickningen, och SHA‑1‑värdet användaren försöker skicka. Om skriptet update avslutas med en icke‑nollkod avslås bara den referensen; andra referenser kan fortfarande uppdateras.

Kroken post-receive körs efter att hela processen är klar och kan användas för att uppdatera andra tjänster eller meddela användare. Den tar samma stdin‑data som kroken pre-receive. Exempel är att skicka e-post till en lista, meddela en CI‑server eller uppdatera ett ärendehanteringssystem – du kan till och med analysera incheckningsmeddelanden för att se om ärenden behöver öppnas, modifieras eller stängas. Detta skript kan inte stoppa uppskickningsprocessen, men klienten kopplar inte ned förrän det är klart, så var försiktig om du försöker göra något som kan ta lång tid.