Hoe Git Hooks te gebruiken voor Commit-automatisering

0
203

Git-hooks zijn bash-scripts die voor of na Git-commando's worden uitgevoerd, zoals verbindt en pusht. Ze stellen je in staat om repetitieve acties in je repository te automatiseren, evenals filters en controles toe te passen op je Git-workflow.

Wat zijn Git Hooks?

Git-hooks zijn eigenlijk gewoon bash-scripts met een speciale naam, in de map .git/hooks/. Git zal deze functies automatisch aanroepen bij het uitvoeren van bepaalde taken, zodat je kunt “hook” in de Git-workflow om deze met uw eigen code te wijzigen.

Git-repositories worden geïnitialiseerd met een paar voorbeelden; het enige dat u hoeft te doen om ze toe te passen, is de extensie verwijderen. Dit betekent dat je maar één script per hook kunt hebben, dus als je meerdere dingen wilt doen, moet je ze combineren of delegeren aan andere scripts.

Dus waar kun je ze voor gebruiken? Welnu, elke taak die een bash-script kan uitvoeren, zal werken. Twee veelvoorkomende use-cases zijn geautomatiseerd testen en het toepassen van filters/controles op uitgaande commits.

Tests zijn een belangrijk onderdeel van elke workflow. Hoewel Git-hooks absoluut geen vervanging zijn voor een goede pijplijn voor continue integratie/continue implementatie (CI/CD), die tests uitvoert voordat ze worden beoordeeld en geïmplementeerd, kun je ze lokaal uitvoeren om fouten op te sporen voordat ze verdwijnen.

Advertentie< br>

Evenzo kan het erg handig zijn om de inhoud van commits te controleren om te voorkomen dat er ongewenste code wordt gepusht, hoewel dit wel vereist dat je slim genoeg bent om het probleem op te vangen voordat het een probleem wordt. Als je vaak foutopsporingscode gebruikt die nooit zou moeten worden vastgelegd, kun je dat testen en voorkomen.

Er zijn veel Git hooks waaruit je kunt kiezen, waarover je kunt lezen in de documentatie van Git, maar de handige zijn:

  • pre-commit, post -commit
  • pre-push
  • post-checkout
  • commit-msg

Elke hook zal argumenten opnemen om het script, waartoe je toegang hebt met $1, $2, etc.

Git Hooks delen

Git hooks zijn alleen voor de lokale repository en worden niet naar de remote gepusht. Je bent vrij om welke Git hooks je maar wilt in te stellen zonder je collega's te beïnvloeden, dus je zou bijvoorbeeld zonder problemen een lokale testomgeving kunnen opzetten die afhankelijk is van je pc-setup, bij elke commit .

Als je Git-hooks echt met je team wilt delen, kun je een nieuwe map voor ze maken die in Git wordt bijgehouden, zoals .githooks, en de configuratiewaarde instellen voor core.hooksPath:

git config core.hooksPath .githooks

Net als standaard hooks is deze configuratie echter per repo, dus je team zal ook deze configuratiewaarde moeten instellen.

Hoe Git Hooks te gebruiken

h2>

Zoals de meeste automatiseringstechnieken, is het grotendeels aan jou en de workflow van je repository hoe je Git hooks gebruikt, maar er zijn een paar veelvoorkomende gebruiksgevallen.

Advertentie

Als je de inhoud van commits wilt controleren, kun je git diff gebruiken om de regel-voor-regel diff weer te geven, en dan grep het om overeenkomsten te vinden. In dit geval blokkeert het al het gebruik van de functie Debug.Log door af te sluiten met een code die niet nul is:

if test $(git diff –cached | grep -E “Debug.Log (” | wc -l) != 0 en verlaat vervolgens 1 fi

Of je kunt het daadwerkelijke commit-bericht testen. Het pre-push-voorbeeld gebruikt een vergelijkbare test, maar greps de uitvoer van git rev-list in plaats daarvan. Dit controleert voor commits gemarkeerd als work-in-progress (WIP) en weigert ze te pushen.

Een andere veelvoorkomende use-case is het automatisch uitvoeren van tests. Het is aan jou of je dat bij elke commit wilt doen, of net voordat wijzigingen naar de afstandsbediening worden gepusht.

In beide gevallen is het zo simpel als het uitvoeren van je test commando, de exit-status van het laatste commando krijgen en een foutmelding geven als het mislukt. In dit voorbeeld worden tests uitgevoerd voor een .NET-app:

#!/bin/sh exec dotnet-test “./UnitTests/UnitTests.csproj” –filter “Category!=Integration” als [ $? -ne 0]; dan echo “Tests moeten slagen voordat ze worden vastgelegd!” exit 1 fi

Er zijn enkele hulpmiddelen om hierbij te helpen; Husky zal gemakkelijk NodeJS-tests uitvoeren met een configuratie-instelling in package.json, die ook van toepassing is op al uw teamgenoten.

{ “husky”: { “hooks”: { “pre-commit”: “npm test” , “pre-push”: “npm test”, “…”: “…” } } } Advertentie

Dit is echter geen vervanging voor het hebben van daadwerkelijke tests op de gezaghebbende repo . Er zijn scenario's waarin uw lokale tests kunnen slagen, maar tests op afstand zouden mislukken, namelijk in gevallen waarin u niet alle wijzigingen voorbereidt om te worden gepusht.