8.3 Git aanpassen - Git Hooks

De eerste vier hooks hebben te maken met het proces van committen.

De pre-commit hook wordt het eerst aangeroepen, voordat je zelfs een commit bericht begint te typen. Het wordt gebruikt om de snapshot die op het punt staat te worden gecommit te inspecteren, om te zien of je iets vergeten bent, om er zeker van te zijn dat de tests slagen of om de code te controleren op iets waar je het op gecontroleerd wilt hebben. Als dit script met niet-nul wordt beëindigd breekt de commit af, al kan je er altijd nog omheen met git commit --no-verify. Je kunt dingen doen als de code op stijl controleren (lint of iets vergelijkbaar aanroepen), controleren op witruimtes aan het eind van regels (de standaard hook doet precies dat), of controleren of nieuwe methoden goed zijn gedocumenteerd.

De prepare-commit-msg hook wordt aangeroepen voordat de commit bericht tekstverwerker wordt opgestart, maar nadat het standaard bericht gemaakt is. Dit geeft je de ruimte om het standaard bericht aan te passen voordat de commit auteur deze ziet. Deze hook heeft een aantal parameters: het pad naar het bestand dat het commit bericht op dat moment bevat, het type commit en de SHA-1 van de commit als het een amended (gewijzigde) commit betreft. Deze hook is over het algemeen niet nuttig voor normale commits; maar is daarentegen goed voor commits waar het standaard bericht automatisch is gegenereerd, zoals commit berichten van een sjabloon, merge commits, squashed commits en amended commits. Je kunt het gebruiken in combinatie met een commit sjabloon om via een programma informatie in te voegen.

De commit-msg hook krijgt één parameter, en dat is weer het pad naar een tijdelijk bestand dat het commit bericht bevat die door de ontwikkelaar is geschreven. Als dit script met een niet-nul waarde eindigt, zal Git het commit proces afbreken, en daarmee kan je dit gebruiken om de status van het project of het commit bericht te valideren voordat je toestaat dat een commit doorgaat. In de laatste paragraaf van dit hoofdstuk zullen we laten zien hoe deze hook te gebruiken om te controleren dat het commit bericht voldoet aan een vereist patroon.

Als het gehele commit proces is voltooid wordt de post-commit hook aangeroepen. Deze krijgt geen enkele parameter, maar je kunt de laatste commit eenvoudig te pakken krijgen door git log -1 HEAD aan te roepen. Meestal wordt dit script gebruikt voor het doen van meldingen of iets vergelijkbaars.

Je kunt drie hooks aan de kant van het werkstation inrichten voor een op e-mail gebaseerde workflow. Ze worden alle aangeroepen door het git am commando, dus als je dat commando niet gebruikt in je workflow, kan je dit gedeelte rustig overslaan en doorgaan naar de volgende paragraaf. Als je patches per e-mail ontvangt die door git format-patch zijn gemaakt, kunnen een aantal van deze behulpzaam zijn.

De eerste hook die wordt aangeroepen is applypatch-msg. Deze krijgt een enkele argument: de naam van het tijdelijke bestand dat het voorgestelde commit bericht bevat. Git breekt het patchen af als dit script met niet-nul eindigt. Je kunt deze gebruiken om je ervan te verzekeren dat het commit bericht juist geformatteerd is, of het bericht normaliseren door met het script deze ter plaatse te bewerken.

De volgende hook die aangeroepen wordt als patches met git am worden toegepast is pre-applypatch. Ietwat verwarrend, wordt deze na het toepassen van een patch aangreoepen maar voordat een commit gemaakt wordt, dus je kunt het gebruiken om de snapshot te inspacteren voordat de commit gemaakt wordt. Je kunt tests uitvoeren of op een andere manier de werk-tree met dit script inspecteren. Als er iets ontbreekt of de tests slagen niet, zal het eindigen met niet-nul het git am script afbreken zonder de patch te committen.

De laatste hook die wordt aangeroepen met een git am operatie is post-applypatch, die wordt aangeroepen nadat de commit gemaakt is. Je kunt deze gebruiken om een groep of de auteur van de patch een bericht te sturen van dat je de patch hebt gepulld. Je kunt het patching proces niet stoppen met dit script.

De pre-rebase hook wordt aangeroepen voordat je ook maar iets rebaset en kan het proces stoppen door met niet-nul te eindigen. Je kunt deze hook gebruiken om het rebasen van commits die al zijn gepusht te weigeren. Het voorbeeld pre-rebase hook die Git installeert dit dit, al doet het een aantal aannamen die misschien niet van toepassing zijn op jouw workflow.

De post-rewrite hook wordt aangeroepen door commando’s die commits vervangen, zoals git commit --amend en git rebase (echter weer niet door git filter-branch). Het enige argument is het commando dat herschrijven heeft veroorzaakt, en het ontvangt een lijst van herschrijvingen op stdin. Deze hook heeft veel wat gebruik betreft overeenkomsten met het gebruik van de post-checkout en post-merge hooks.

Nadat je succesvol een git checkout hebt aangeroepen, wordt de post-checkout hook aangeroepen; je kunt deze gebruiken om je werk directory juist in te richten voor jouw project omgeving. Dit zou het binnenhalen van grote binaire bestanden die je niet in versie beheer wilt hebben kunnen inhouden, het automatisch genereren van documentatie of iets van dien aard.

De post-merge hook wordt aangeroepen na een succesvolle merge commando. Je kunt deze gebruiken om gegevens terug te zetten in de werk tree die Git niet kan tracken, zoals permissie gegevens. Deze hook kan op vergelijkbare manier de aanwezigheid van bestanden buiten Git valideren die je misschien naar binnen wilt kopieren als de werk tree wijzigt.

De pre-push hook wordt aangeroepen tijdens git push, nadat de remote refs zijn ge-update maar voordat er objecten zijn verstuurd. Het ontvangt de naam en locatie van de remote als parameters, en een lijst met refs die op het punt staan te worden geactualiseerd via stdin. Je kunt dit gebruiken om een aantal ref updates te valideren voordat er een push plaatsvindt (een niet-nul einde zal de push afbreken).

Git zal nu en dan afval verzamelen (garbage collection) als onderdeel van zijn normale taken, door git gc --auto aan te roepen. De pre-auto-gc hook wordt aangeroepen vlak voordat de garbage collection plaatsvindt, en kan worden gebruikt om aan te geven dat het staat te gebeuren, of deze operatie af te breken als het nu niet goed uitkomt.

Het eerste script die wordt aangeroepen als een push wordt afgehandeld van een werkstation is pre-receive. Deze krijgt een lijst van referenties die worden gepusht vanuit stdin; als het niet-nul eindigt wordt geen enkele geaccepteerd. Je kunt deze hook gebruiken om zaken te doen als het verzekeren dat geen van de bijgewerkte referenties non-fast-forwards zijn, of toegangscontroles uit te voeren voor alle refs en bestanden die met de push worden gewijzigd.

Het update script lijkt erg op het pre-receive script, behalve dat het eenmaal wordt aangroepen voor elke branch die de pusher probeert bij te werken. Als de pusher meerdere branches probeert te pushen, wordt pre-receive maar één keer aangeroepen, terwijl update één keer per branch waarnaar wordt gepusht wordt aangeroepen. In plaats van van stdin te lezen, krijgt dit script drie argumenten: de naam van de referentie (branch), de SHA-1 waar die referentie naar wees voor de push en de SHA-1 die de gebruiker probeert te pushen. Als het update script niet-nul eindigt, wordt alleen die referentie geweigerd, de andere referenties kunnen nog steeds worden geüpdatet.

De post-receive hook wordt aangeroepen zodra het hele proces gereed is, en kan worden gebruikt om andere diensten bij te werken of gebruikers een bericht te sturen. Het krijgt dezelfde stdin gegevens als de pre-receive hook. Voorbeelden omvatten het mailen naar een lijst, continuous integratie services notificeren of een ticket-traceer systeem bij werken - je kunt zelfs de commit berichten doorlezen om te zien of er tickets geopend, gewijzigd of gesloten moeten worden. Dit script kan het push proces niet stoppen, maar het werkstation zal de verbinding niet verbreken voordat dit script geëindigd is, dus wees voorzichtig als je iets probeert te doen wat veel tijd in beslag neemt.