De grondbeginselen van Git hooks: een inleiding<\/h2>\n
Een van de belangrijkste eigenschappen van Git<\/a> zijn de hooks: een krachtig mechanisme waarmee je taken kunt automatiseren, standaarden kunt afdwingen en consistente werkwijzen kunt garanderen gedurende de levenscyclus van een project.<\/p>\n Git hooks zijn scripts die automatisch worden uitgevoerd op specifieke punten in de Git workflow. Je kunt ze gebruiken om het gedrag van Git aan te passen en uit te breiden om aan de behoeften van je project te voldoen. Hooks zorgen ervoor dat de kwaliteit van de code behouden blijft, tests worden uitgevoerd en implementaties soepel verlopen.<\/p>\n Git biedt verschillende soorten hooks, en elke zal op verschillende momenten in de Git workflow geactiveerd worden:<\/p>\n Je vindt hooks in de Hooks worden geactiveerd tijdens verschillende Git acties. Bijvoorbeeld, een pre-commit hook start als je wijzigingen commit, en een pre-push hook start voordat je naar remote pusht<\/a>. Als je meer begrijpt over deze triggers, kun je hooks strategischer inzetten om kwaliteitscontrole te verbeteren en je workflow te stroomlijnen.<\/p>\n Het maken en installeren van basis aangepaste Git hooks kan een complex proces zijn. Maar de basis die je hier zult leren, zal je later voorbereiden op het ontwikkelen van geavanceerde hooks. Laten we een paar concepten doornemen die van toepassing zijn op elke hook die je maakt en installeert.<\/p>\n Het gebruik van het juiste hook type voor jouw specifieke use case is een belangrijke eerste stap. Het begint met het begrijpen van je eigen ontwikkelworkflow en behoeften. Hier is een snelle checklist met overwegingen die je mee kan nemen:<\/p>\n Op dit punt zou je in staat moeten zijn om duidelijke doelen voor je hook te defini\u00ebren. Het kan zelfs zijn dat elke doelstelling een ander type hook vereist. Hoewel het verleidelijk is om scripts te maken voor elk mogelijk scenario, is het een goed idee om je eerst te richten op het aanpakken van kritieke pijnpunten.<\/p>\n Het correct benoemen en plaatsen van aangepaste Git hooks is cruciaal om hun functionaliteit en onderhoudbaarheid te garanderen. Net als met bijvoorbeeld de functies, bestanden, klassenamen\u00a0 van je code, zouden je Git hooks ook consistente en beschrijvende namen moeten hebben.<\/p>\n Als hooks in de loop van de tijd meerdere projecten zullen ondersteunen, als een template, dan wil je misschien voorvoegsels gebruiken – misschien met initialen van developers, een afdeling of een bedrijfsnaam. Over het algemeen gebruiken Git hooks kleine letters en koppeltekens voor de leesbaarheid – bijvoorbeeld, mijn-project-pre-commit<\/b>.<\/p>\n Bovendien, hoewel je Git hooks in de .git\/hooks<\/b> map van je repo kunt opslaan, zouden custom <\/i>hooks in een aparte map in de hoofdmap van het project moeten gaan. Dit voorkomt per ongeluk overschrijven tijdens een Git update. Je wil echter versiebeheer<\/a> voor die hooks willen gebruiken, samen met de rest van de code van je project.<\/p>\n De typische manier om een basic Git hook te schrijven is om een nieuw bestand te maken met de naam van je gekozen hook (zoals pre-commit<\/b>) in je hooks map. We zullen de hook namen later noemen als we het over parameters hebben.<\/p>\n Voordat je een bestand opent om ermee te werken, moet je er zeker van zijn dat het uitvoerbaar is met het volgende commandline fragment:<\/p>\n Vergeet niet om onze placeholders te vervangen door de juiste informatie. We zullen dit fragment door het hele artikel heen gebruiken, omdat het een typische actie zou moeten zijn als je een nieuwe Git hook aanmaakt.<\/p>\n Zodra het bestand uitvoerbaar en open is, kun je je eigen logica toevoegen met de scripttaal van je voorkeur. Dit kan Bash, Python<\/a>, Ruby<\/a> of een andere zijn. Het maken hiervan valt natuurlijk buiten het bereik van wat we hier zullen behandelen. Er zijn later echter enkele pseudocode voorbeelden om specifieke gebruikssituaties en scenario’s te laten zien.<\/p>\n Tot slot, voordat je wijzigingen commit, test je je hook door te proberen de gerelateerde actie uit te voeren (zoals een commit). Dit is de basisaanpak voor het maken van Git hooks, maar er zijn genoeg geavanceerde gebruikssituaties. Daar zullen we het volgende over hebben.<\/p>\n Het maken van basis Git hooks zal iets zijn dat je veel doet gedurende je carri\u00e8re als developer. Er zijn echter genoeg situaties die vragen om meer geavanceerde en complexe hooks. Hierna zullen we kijken naar een aantal use cases en voorbeeld hooks voor een aantal veel voorkomende scenario’s.<\/p>\n Het gebruik van een linter om code styling af te dwingen is een fantastische toepassing voor Git hooks. Het kan helpen om consistente codekwaliteit in je repository te behouden en het zou iets moeten zijn waar je veel waarde uit kunt halen.<\/p>\n Natuurlijk moet je een linter kiezen die past bij de programmeertaal van je project. Black<\/a> is bijvoorbeeld fantastisch voor Python. Wij gaan hier ESLint<\/a> voor JavaScript gebruiken om een pre-commit hook te maken.<\/p>\n Installeer eerst de linter als globaal of lokaal pakket binnen je project. Hiervoor heb je Node.js<\/a> en npm<\/a> nodig:<\/p>\n Navigeer vervolgens naar je hooks directory binnen je repo. Maak je pre-commit bestand aan en schrijf dan een script dat de linter uitvoert op je opgevoerde bestanden. De hook zou de commit moeten voorkomen als de linter problemen vindt. Hier is een simpel voorbeeld:<\/p>\n Zodra je er zeker van bent dat de hook uitvoerbaar is, test hem dan uit door middel van een commit. De pre-commit hook zou de linter moeten uitvoeren. Als er code stijl schendingen zijn, dan zul je de commit niet kunnen voltooien totdat je de problemen opgelost hebt.<\/p>\n Natuurlijk moet je een hook schrijven die werkt met je eigen programmeertaal<\/a> en linter, in overeenstemming met je project. Je zou dit voorbeeld bijvoorbeeld kunnen uitbreiden met linter configuratie-instellingen, integratie met je bouwproces en meer.<\/p>\n Het implementeren van een pre-commit hook om tests uit te voeren voor een commit is een uitstekende manier om potenti\u00eble problemen in een vroeg stadium op te vangen. Op deze manier kun je ervoor zorgen dat je alleen betrouwbare code commit.<\/p>\n Voor dit voorbeeld gebruiken we het Jest test framework<\/a> voor JavaScript. Je zult iets willen installeren dat geschikt is voor jouw project (zoals altijd):<\/p>\n Zoals met elke hook, navigeer je naar je hooks directory, maak je een nieuw bestand aan, geef je het een naam en maak je het uitvoerbaar. Schrijf vanaf hier een script dat tests uitvoert op alle opgevoerde bestanden voor de commit. Hier is een ruwe template:<\/p>\n Wanneer je wijzigingen probeert te committen, zal de hook je tests uitvoeren op de opgevoerde bestanden. De commit zal stoppen voor alle mislukte tests, en je moet de problemen aanpakken voordat je opnieuw commit.<\/p>\n Een uitstekende manier om het releaseproces te stroomlijnen is het automatiseren van versiebeheer en taggen binnen Git. Dit zorgt voor consistente versiebeheer in je codebase.<\/p>\n Om te beginnen moet je een versiebeheerschema kiezen dat geschikt is voor je project. Dit valt buiten het bereik van dit artikel, maar veel voorkomende schema’s zijn Semantic Versioning (SemVer) of een custom versiebeheerpatroon.<\/p>\n Bepaal vervolgens wat je hook precies gaat doen. Het zou bijvoorbeeld de huidige versie kunnen lezen, deze verhogen volgens een gekozen schema en de benodigde bestanden bijwerken met de nieuwe versie. Je zult ook een script willen schrijven voor het maken van tags gebaseerd op de versie, dat Git commando’s gebruikt om lichtgewicht of geannoteerde tags te maken.<\/p>\n Als je eenmaal je bestand hebt gemaakt en de rechten hebt ingesteld, kun je beginnen met het schrijven van je hook. Dit kan een complexe en zeer specifieke hook zijn, die zelfs van project tot project kan veranderen. De meeste hooks van dit type zullen echter het volgende bevatten:<\/p>\n Vanaf hier moet het script het versiebestand bijwerken met het nieuwe nummer, een lichtgewicht tag aanmaken met de nieuwe versie en optioneel de nieuwe tag naar een remote repository pushen. Zodra je wijzigingen vastlegt, zal de hook ervoor zorgen dat iedere vastlegging wordt geassocieerd met een juiste versie en tag.<\/p>\n Je zult deze hook waarschijnlijk nog verder willen aanpassen aan de eisen van je project. Je zou bijvoorbeeld zaken als het aanmaken van initi\u00eble tags, het omgaan met versieconflicten en het updaten van versieverwijzingen in bestanden kunnen afhandelen.<\/p>\n Een van de redenen dat Git hooks zo krachtig zijn, is de manier waarop ze omgaan met dynamische variabelen. Het kan echter een complex concept zijn om te begrijpen. Hierna zullen we zowel omgevingsvariabelen als hookparameters bekijken – te beginnen met de laatste.<\/p>\n Hooks kunnen specifieke parameters van Git ontvangen om toegang te krijgen tot contextuele informatie van je hoofdcodebase. Git stelt automatisch parameters in tijdens run-time, en hoewel je ze meestal niet specifiek hoeft te defini\u00ebren, moet je ze misschien wel declaren. Het is essentieel om deze te begrijpen om effectieve hooks te ontwikkelen.<\/p>\n Hier is een overzicht van de belangrijkste punten over hookparameters:<\/p>\n Als je een parameter zou toevoegen die de hook niet kan aanroepen, zou het script deze over het algemeen niet kunnen gebruiken. Parameters zijn specifiek voor een bepaalde hook en uitvoeringscontext. Om problemen te voorkomen, moet je alleen gedocumenteerde parameters gebruiken. Je kunt<\/i> echter de waarde van een positionele parameter toewijzen aan een andere variabele en deze vervolgens gebruiken in je script:<\/p>\n In dit geval zal de variabele Merk op dat je in sommige gevallen standard input ( Omdat elke Git hook zijn eigen parameters heeft, zul je waarschijnlijk een referentie nodig hebben om te achterhalen wat ze zijn voor jouw specifieke applicatie. Het goede nieuws is dat er een paar manieren zijn om dit te doen.<\/p>\n Bijvoorbeeld, de offici\u00eble Git hooks documentatie<\/a> bevat een aantal van de meest voorkomende parameters. Maar de beste aanpak is om een van de voorbeeld Git hooks te openen. Deze bestaan uit een mini-gids over hoe de hook te scripten en zullen parameter definities voor je bevatten:<\/p>\n Deze zijn een uitstekende manier om Git hooks onder de knie te krijgen en kunnen je zelfs een eind op weg helpen bij het coderen ervan.<\/p>\n Git hooks kunnen argumenten ophalen van commandoregel argumenten, en Deze omgevingsvariabelen<\/a> laten je het gedrag van je Git hooks aanpassen en beslissingen nemen gebaseerd op verschillende aspecten van de Git workflow. Op deze manier kun je dynamische en context-bewuste Git hooks maken. Je kunt ze bijvoorbeeld gebruiken om commitberichten te valideren, toegang tot specifieke branches te regelen of aangepaste acties te starten op basis van de identiteit van de auteur.<\/p>\n Het opsommen van alle omgevingsvariabelen valt ook buiten het bereik van dit artikel. We raden je aan om de Git documentatie<\/a> en voorbeeldhooks te bekijken voor hints over welke variabelen het zal gebruiken.<\/p>\n Git stelt meestal automatisch verschillende omgevingsvariabelen in, afhankelijk van de hook die het callt. Als zodanig kan dit problemen voor je veroorzaken als je je niet bewust bent van wat er ingesteld wordt. Neem bijvoorbeeld het volgende resultaat voor de Gelukkig is er een manier om te testen wat Git zal doen<\/a> met omgevingsvariabelen door een klein fragment binnen je hook te gebruiken:<\/p>\n Om de code samen te vatten: regel 2 print het script dat op dat moment draait; regel 3 stelt alle omgevingsvariabelen in om weer te geven, filtert ze dan op die met “GIT” in de naam; regel 4 print de huidige werkmap.<\/p>\n Als je dit uitvoert, zie je uitvoer die overeenkomt met de omgevingsvariabelen die bij je hook horen. Vanaf hier heb je de kennis om ervoor te zorgen dat je eigen Git hooks omgevingsvariabelen kunnen gebruiken op de manier die jij wilt.<\/p>\n Het optimaal beheren van Git hooks binnen een team of organisatie is cruciaal om consistente development te garanderen en je workflows<\/a> op een effici\u00ebnte manier te automatiseren. Neem bijvoorbeeld het toewijzen van een speciale hooks directory. Er zijn twee adviezen die we je hier kunnen geven:<\/p>\n Hoe waarschijnlijker het is dat hooks in meerdere projecten voorkomen, hoe groter het belang van documentatie. Je moet uitgebreide documentatie bijhouden die het doel, het gebruik en de configuratieopties voor elke hook in de repo beschrijft. Codebeoordelingen en updatestrategie\u00ebn voor deze globale hooks zijn ook essentieel.<\/p>\n We raden je ook aan om aangepaste hooks op te slaan in het versiebeheersysteem (VCS), samen met de codebase van je project. Dit zorgt ervoor dat het hele team toegang heeft tot de hele bibliotheek van hooks.<\/p>\n Server-side hooks worden uitgevoerd op de server die de centrale Git repo host. Als zodanig kun je beleidsregels afdwingen, controles uitvoeren of acties starten aan de server kant.<\/p>\n Je hebt twee opslagmogelijkheden voor je server-side hooks: binnen het VCS naast je project of in aparte repositories.<\/p>\n Er zijn twee voordelen aan het gebruik van je VCS om hooks voor de server op<\/a> te slaan. Ten eerste kun je ervoor zorgen dat de hooks dezelfde versiebeheer en onderhoud hebben als de rest van je codebase. Ten tweede hoef je maar \u00e9\u00e9n repository te clonen om toegang te krijgen tot zowel de projectcode als de hooks.<\/p>\n Echter, afhankelijk van de aard van de specifieke hooks, kan het opslaan ervan in dezelfde repo beveiligingsproblemen opleveren als die hooks toegang hebben tot gevoelige informatie. Bovendien, als de hooks complex zijn of specifieke configuraties vereisen, kan het de complexiteit van je hoofdrepository vergroten.<\/p>\n Door server-side hooks in aparte repo’s te bewaren, kun je ze onafhankelijk van je codebase updaten en versiebeheer uitvoeren, wat potenti\u00eble conflicten kan verminderen. Deze modulariteit kan meer flexibiliteit bieden.<\/p>\n Bovendien kun je die hooks opslaan in repositories met beperkte toegang. Dit helpt je het risico op blootstelling van gevoelige gegevens te verminderen.<\/p>\n Het onderhouden van meerdere repositories<\/a> kan daarentegen extra inspanning kosten. Als hooks afhankelijk zijn van specifieke versies van je hoofdcode, kan het een uitdaging zijn om wijzigingen tussen je repositories te co\u00f6rdineren.<\/p>\n Het automatiseren van hookinstallaties in meerdere repositories kan tijd besparen en zorgen voor consistentie in je ontwikkelworkflow. Door scripts en templates te gebruiken, kun je eenvoudig hooks installeren in verschillende repositories zonder handmatige tussenkomst.<\/p>\n Het proces begint met een speciale repository die je algemene hooks bevat. Je wilt deze standaardiseren: vermijd bijvoorbeeld het hardcoden van paden of waarden die specifiek zijn voor een enkele repo.<\/p>\n Vanaf hier kun je beginnen met het schrijven van je installatiescript. De volgende pseudocode zal bijvoorbeeld de templaterepo van een hook klonen en de hooks kopi\u00ebren (of ‘symlinken’)<\/a> naar de .git\/hooks<\/b> map van elke repository:<\/p>\n Zodra je je wijzigingen hebt opgeslagen, kun je het installatiescript uitvoeren voor elke repo waar je de hooks wilt installeren:<\/p>\n Breng wijzigingen aan in de templaterepository wanneer je hooks wilt bijwerken of toevoegen. De volgende keer dat je het installatiescript in een repository uitvoert, worden de bijgewerkte hooks ge\u00efnstalleerd.<\/p>\n Met Git templates kun je algemene hooks en configuraties defini\u00ebren voor nieuwe repositories. Ze bieden een systematische aanpak om je te helpen setups, configuraties en andere elementen te automatiseren als je nieuwe repositories maakt of kloont. Zo kun je ervoor zorgen dat elke repo voldoet aan de door jou gevolgde practices.<\/p>\n Als je eenmaal een templatemap hebt gemaakt en je hookscripts hebt toegevoegd, kun je Git configureren om de map te gebruiken als template voor nieuwe repositories. Je kunt dit globaal of lokaal per gebruiker instellen.<\/p>\n Voor globale configuraties wijs je naar je hooks-template map:<\/p>\n Voor lokale configuraties kun je de exacte repo opgeven:<\/p>\n Als je een nieuw repository aanmaakt met Tenslotte, waar templatehooks generiek kunnen zijn, kun je ook custom hooks toestaan gebaseerd op specifieke behoeften. Een script zou bijvoorbeeld kunnen controleren op een repository-specifiek hook configuratiebestand en het gebruiken als het aanwezig is.<\/p>\n Het gebruik van Git hooks kan waardevol zijn voor procesautomatisering en het afdwingen van best practices. Maar dit kan ook kwetsbaarheden met zich meebrengen als je je hooks niet goed genoeg beheert.<\/p>\n Hier is een korte lijst van werkwijzen die je zou kunnen implementeren voor je eigen hooks:<\/p>\n Je wilt ook een grondig en uitgebreid test- en controleproces implementeren. Dit zal kwetsbaarheden en andere fouten in de toekomst helpen voorkomen.<\/p>\n We gaan het nu hebben over het implementeren van goede validatie en foutafhandeling<\/a> voor je hooks. Dit is cruciaal om betrouwbaarheid, stabiliteit en veiligheid te garanderen.<\/p>\n Je wil bijvoorbeeld altijd alle invoer of parameters valideren die je hookscripts ontvangen. Er is echter nog veel meer dat je kunt doen om een goede validatie te garanderen. Je kunt ervoor zorgen dat de repository in de verwachte state is om de hook succesvol te laten draaien. Bijvoorbeeld, in een pre-commit hook, controleer of je de benodigde bestanden test voor de commit.<\/p>\n Foutafhandeling zal ook waardevol zijn. Exit codes zijn net zo cruciaal in hooks als in je codebase, net als foutlogs en informatieve foutmeldingen. Graceful failure zou hier je doel moeten zijn, net als bij grotere codebases.<\/p>\n Natuurlijk kunnen je hooks in een echt scenario complexere validatie en foutafhandeling nodig hebben. Dit betekent dat regelmatig testen nog belangrijker is dan voorheen.<\/p>\n Ongelukjes gebeuren, dus het instellen van je Git hooks om deze ongewenste destructieve acties te voorkomen is cruciaal om dataverlies of schade te voorkomen. Hooks kunnen in wezen fungeren als vangnetten door de gebruiker te vragen om mogelijk schadelijke acties.<\/p>\n Pre-ontvangst en pre-commit hooks werken hier goed. Laten we snel bekijken hoe beide kunnen helpen:<\/p>\n Echter, welke praktijken je ook implementeert, ze moeten veilig, effici\u00ebnt en optimaal zijn voor jouw behoeften. Dit vereist een grondige review en teststrategie.<\/p>\n Het nakijken en testen van hooks is essentieel om er zeker van te zijn dat ze goed werken en aansluiten op je ontwikkel workflow. Beoordelingen door collega’s, duidelijke documentatie, een overvloed aan commentaar en meer kunnen ervoor zorgen dat hooks klaar zijn voor productie.<\/p>\n Als het op testen aankomt, is het belangrijk om dit ge\u00efsoleerd te doen met diverse voorbeeldgegevens. Je zou ook geautomatiseerde regressie- of integratietests kunnen implementeren.<\/p>\n Tot slot raden we je aan om hooks te testen in verschillende omgevingen (zoals je ontwikkel-<\/a>, test-<\/a> en productieservers<\/a>) om ervoor te zorgen dat ze consistent gedrag vertonen. Een real-time logging setup zal hierbij helpen, omdat het kan laten zien wat er gebeurt als gegevens van server naar server gaan.<\/p>\n Zoals met elke codebase, kan het zijn dat je ook je hooks moet troubleshooten – zelfs na een paar pogingen. In feite, wat voor type Git hook je ook hebt, je zult merken dat dezelfde fouten steeds weer opduiken. Veel van deze zullen eenvoudige problemen zijn die invloed hebben op alle soorten projecten, zoals syntaxisfouten, toestemmingsproblemen, het gebruik van relatieve of hardcoded paden, en nog veel meer.<\/p>\n Het is echter ook een goed idee om te controleren op ontbrekende dependencies, omdat sommige hooks afhankelijk zijn van externe tools, bestanden of bibliotheken. Als zodanig moet je ze beschikbaar maken in de omgeving waar je de hook uitvoert.<\/p>\n Er zijn echter specifieke problemen die kunnen opduiken met Git hooks. Bijvoorbeeld, hooks moeten afsluiten met een non-zero statuscode om een mislukking aan te geven. Bovendien zouden hooks geen oneindige loops moeten bevatten. Hiermee kun je namelijk onverwacht gedrag veroorzaken en je workflow verstoren.<\/p>\n Je kunt ook merken dat conflicten tussen twee hooks onbedoelde interacties en gevolgen hebben. Ook zogenaamde ‘race conditions’<\/a> kunnen je verwachtingen verstoren. Dit is wanneer twee of meer hooks door vergelijkbare gebeurtenissen worden geactiveerd, maar de ene eerder wordt voltooid dan de andere – dit heeft invloed op het eindresultaat dat je verwacht.<\/p>\n Hier zijn reviews en tests van vitaal belang. Het bijhouden van documentatie is ook belangrijk om problemen te voorkomen en ervoor te zorgen dat hooks werken zoals je verwacht.<\/p>\n Over documentatie gesproken, Git’s eigen referentiemateriaal<\/a> is essentieel leesvoer. In feite, samen met dit artikel en misschien de onafhankelijke Git Hooks<\/a> gidssite (met behulp van GitHub Pages<\/a>), zou je niet al te veel leesmateriaal nodig moeten hebben.<\/p>\n Je zou echter ook naar apps kunnen kijken om je te helpen Git hooks te beheren. Lefthook<\/a> heeft regelmatige updates en veel ondersteuning op GitHub, terwijl Husky<\/a> geweldig is voor het linten van je commitberichten.<\/p>\n CI\/CD pijplijnen werken goed met Git hooks, omdat die scripts je kunnen helpen taken te automatiseren, consistente kwaliteit te garanderen en veiligheidscontroles te bieden.<\/p>\n Met pre-commit hooks kun je bijvoorbeeld code kwaliteitscontroles uitvoeren, zoals linting, statische analyse en opmaak. Als het op testen aankomt, kun je eenheidstests, testsuites of andere geautomatiseerde controles starten in de pre-commit fase. Aan de andere kant kun je met pre-push hooks integratietests, beveiligingsscans<\/a> en meer uitvoeren.<\/p>\n Er zijn veel voordelen die je kunt halen uit het gebruik van hooks binnen je CI\/CD pipelines:<\/p>\n Omdat je met Kinsta’s API<\/a> CI\/CD pipelines<\/a>\u00a0kunt opzetten, kun je ook hier Git hooks integreren. Met Kinsta kun je je hele repo pullen<\/a> vanaf een externe locatie en je kunt pushen met een externe plugin zoals WP Pusher<\/a>.<\/p>\n Natuurlijk betekent dit ook dat je de optie hebt om Git hooks te gebruiken. Als zodanig kan je Kinsta installatie gebruik maken van deze krachtige scripts binnen je repo.<\/p>\n\n
.git\/hooks<\/code> map van je Git repository. Er zijn daar ook voorbeeldhooks – je kunt ze gebruiken als templates om je eigen custom scripts te maken. De hooks hebben betrekking op een reeks acties en gebruiken een sample- <\/b>achtervoegsel als referentie:<\/p>\n![\"Een](\"https:\/\/kinsta.com\/wp-content\/uploads\/2023\/10\/sample-hooks-directory.png\" "\\"Sample")
Zo maak en installeer je custom Git hooks<\/h2>\n
Een geschikt type hook kiezen<\/h3>\n
\n
Custom Git hooks benoemen en plaatsen<\/h3>\n
Een basic custom Git hook maken<\/h3>\n
chmod +x path\/to\/file\/hook-name<\/code><\/pre>\nGeavanceerde custom hooks maken en installeren<\/h2>\n
Een hook maken die code styling afdwingt met linters<\/h3>\n
npm install eslint --save-dev<\/code><\/pre>\n#!\/bin\/sh\n\n# Stash unstaged changes (optional but recommended)\ngit stash -q --keep-index\n\n# Run the linter on staged files\nnpm run lint # Replace with the appropriate linting command\nLINT_RESULT=$?\n\n# Unstash the stashed changes (optional but recommended)\ngit stash pop -q\n\n# Exit with the linter's exit code\nexit $LINT_RESULT<\/code><\/pre>\nEen hook gebruiken voor het uitvoeren van testen voor een commit<\/h3>\n
npm install jest --save-dev<\/code><\/pre>\n#!\/bin\/sh\n\n# Stash unstaged changes (optional but recommended)\ngit stash -q --keep-index\n\n# Run tests on staged files\nnpm test # Replace with the appropriate test command\nTEST_RESULT=$?\n\n# Unstash the stashed changes (optional but recommended)\ngit stash pop -q\n\n# Exit with the test's exit code\nexit $TEST_RESULT<\/code><\/pre>\nEen hook ontwikkelen voor het automatiseren van versiebeheer en labelen<\/h3>\n
\n
1.2.3<\/code>) verhoogt en de nieuwe versie teruggeeft.<\/li>\n0<\/code> voor major, 1<\/code> voor minor, 2<\/code> voor patch.<\/li>\n<\/ul>\nHook parameters en omgevingsvariabelen begrijpen<\/h2>\n
Hoe parameters aan hooks worden doorgegeven<\/h3>\n
\n
$1<\/code> verwijst naar de eerste parameter, $2<\/code> naar de tweede parameter, enzovoort. Deze parameters zijn niet willekeurig; ze hebben specifieke betekenissen en doelen. Als zodanig, hoewel ze niet ‘officieel’ zijn, vertegenwoordigen ze geaccepteerde conventies bij het benaderen van de waarden van parameters.<\/li>\n$1<\/code> bevat vaak het pad naar een bestand, terwijl $2<\/code> de bron van een actie kan zijn.<\/li>\n<\/ul>\n#!\/bin\/sh\n\n# Assign $1 to the variable EXAMPLE\nEXAMPLE=$1\n\n# Use EXAMPLE variable\necho \"The commit message file is: $EXAMPLE\"<\/code><\/pre>\nEXAMPLE<\/code> dezelfde waarde hebben als $1<\/code>, wat het pad is naar het bestand van het commit-bericht. Het gebruik van de gedocumenteerde variabelenamen maakt je code echter begrijpelijker.<\/p>\nstdin<\/code><\/a> ) zult gebruiken om parameters te defini\u00ebren, in welk geval je die elementen in je hooks moet verwerken.<\/p>\nGit hook parameter waarden en definities vinden<\/h4>\n
![\"Een](\"https:\/\/kinsta.com\/wp-content\/uploads\/2023\/10\/sample-git-hook.png\")
Omgevingsvariabelen<\/h3>\n
stdin,<\/code> zoals we hebben besproken. Ze kunnen echter ook argumenten ophalen uit de omgeving zelf zoals die draait binnen een bash<\/code> shell.<\/p>\nDe waarden van omgevingsvariabelen testen<\/h3>\n
GIT_REFLOG_ACTION<\/code> variabele voor de pre-rebase en post-merge hooks:<\/p>\n\n
pre-rebase<\/code>. GIT_REFLOG_ACTION=rebase<\/code><\/li>\npost-merge<\/code>. GIT_REFLOG_ACTION=\u2019pull other master\u2019<\/code><\/li>\n<\/ul>\n#!\/bin\/bash\n\necho Running $BASH_SOURCE\nset | egrep GIT\necho PWD is $PWD<\/code><\/pre>\nTips en trucs om je Git Hooks te beheren en te delen<\/h2>\n
\n
Server-side Git hooks gebruiken<\/h3>\n
Server-side hooks opslaan met behulp van een VCS<\/h4>\n
Server-side hooks opslaan in aparte repo’s<\/h4>\n
Hookinstallaties automatiseren<\/h3>\n
# Example installation script\n# Usage: .\/install_hooks.sh \/path\/to\/repository\nTEMPLATE_REPO=\"https:\/\/github.com\/yourusername\/hooks-template.git\"\nREPO_PATH=\"$1\"\nREPO_NAME=$(basename \"$REPO_PATH\")\n\n# Clone the template repository\ngit clone --depth 1 \"$TEMPLATE_REPO\" \"$REPO_NAME-hooks\"\n\n# Copy or symlink hooks to the repository\ncp -r \"$REPO_NAME-hooks\/hooks\" \"$REPO_PATH\/.git\/\"\nrm -rf \"$REPO_NAME-hooks\"\necho \"Hooks installed in $REPO_NAME\u201d<\/code><\/pre>\n.\/install_hooks.sh \/path\/to\/repository1\n.\/install_hooks.sh \/path\/to\/repository2\n# \u2026<\/code><\/pre>\nGit templates<\/h3>\n
git config --global init.templateDir \/path\/to\/hooks-template<\/code><\/pre>\ngit init --template=\/path\/to\/hooks-template<\/code><\/code><\/pre>\ngit init<\/code> of een bestaand repository clonet, dan zal Git automatisch de inhoud van je hooks-template map naar de .git<\/b> map in de nieuwe repo kopi\u00ebren.<\/p>\nBest practices om je te helpen om veilig Git hooks te onderhouden<\/h2>\n
\n
Validatie<\/h3>\n
![\"Een](\"https:\/\/kinsta.com\/wp-content\/uploads\/2023\/10\/hook-exit-code.png\")
Onopzettelijke destructieve acties<\/h3>\n
\n
--force<\/code>) of verwijderen van branches<\/a> bij betrokken zijn.<\/li>\nforce push<\/code> commando’s in commitberichten. Toon van daaruit een waarschuwing of foutmelding voor de gebruiker.<\/li>\n<\/ul>\nGit Hooks beoordelen en testen<\/h3>\n
Problemen met hooks oplossen<\/h2>\n
![\"De](\"https:\/\/kinsta.com\/wp-content\/uploads\/2023\/10\/git-hooks-website.png\")
De voordelen van het integreren van hooks in continue integratie (CI\/CD) pipelines<\/h2>\n
\n
![\"De](\"https:\/\/kinsta.com\/wp-content\/uploads\/2023\/10\/wppusher-home-page.png\")
Samenvatting<\/h2>\n