Git-hooks aan de serverzijde

In de vorige les leerden we over Git-hooks aan de clientzijde. Nu bekijken we hooks aan de serverzijde, die op de Git-server zelf werken.

Deze hooks zijn krachtige hulpmiddelen om repositorybrede beleidsregels af te dwingen en taken te automatiseren vóór of nadat wijzigingen in de centrale repository zijn geaccepteerd.

Het belangrijkste verschil tussen hooks aan de clientzijde en aan de serverzijde is waar ze worden uitgevoerd:

• Hooks aan de clientzijde: Worden op je lokale machine uitgevoerd vóór acties zoals committen of pushen. Ze helpen lokale best practices af te dwingen.
• Hooks aan de serverzijde: Worden uitgevoerd op de centrale Git-server nadat je wijzigingen hebt gepusht, maar voordat deze volledig zijn geïntegreerd. Ze zorgen ervoor dat repositorybrede regels door iedereen worden nageleefd.

Hooks aan de serverzijde bieden een sterkere garantie dat alle bijdragers de regels naleven.

Hooks aan de serverzijde staan in de map hooks van je bare repository op de server.

Een bare repository is een repository zonder werkmap – deze bevat alleen de Git-metagegevens. Wanneer je naar een externe repository pusht, push je naar een bare repository.

Net als hooks aan de clientzijde zijn het uitvoerbare scripts die Git op specifieke momenten in de werkstroom uitvoert.

De hook pre-receive is een van de meest gebruikte hooks aan de serverzijde. Deze wordt één keer per push uitgevoerd, voordat verwijzingen (zoals branches of tags) worden bijgewerkt.

De hook ontvangt een lijst met alle verwijzingen die worden gepusht en hun oude/nieuwe commit-ID's. Als dit script wordt afgesloten met een status die niet nul is, wordt de volledige push geweigerd en worden er geen verwijzingen bijgewerkt.

Dit maakt de hook ideaal voor het afdwingen van globale beleidsregels.

De hook pre-receive is ideaal voor:

• Het afdwingen van naamgevingsconventies voor branches: Alle nieuwe branches moeten bijvoorbeeld beginnen met "feature/", "bugfix/" enzovoort.
• Het valideren van commitberichten: Ervoor zorgen dat elk commitbericht een ticket-ID bevat of een specifieke indeling volgt.
• Het voorkomen van pushes naar beschermde branches: Directe pushes naar main of develop blokkeren.
• Code controleren op gevoelige informatie: Eenvoudig scannen op inloggegevens.

Dit is een conceptueel voorbeeld van een pre-receive-script dat directe pushes naar de branch main voorkomt. Als iemand naar main probeert te pushen, wordt de push geweigerd.

Dit script wordt als pre-receive in de map hooks van de bare repository op de server geplaatst en uitvoerbaar gemaakt.

De hook update lijkt op pre-receive, maar wordt één keer uitgevoerd voor elke verwijzing die door een push wordt bijgewerkt.

De hook ontvangt drie argumenten: de naam van de verwijzing, de naam van het oude object en de naam van het nieuwe object. Als een update-script wordt afgesloten met een status die niet nul is, wordt alleen de update van die specifieke verwijzing geweigerd.

Hierdoor is een fijnmazigere controle over afzonderlijke branch-updates mogelijk.

De hook update is nuttig voor:

• Het afdwingen van fast-forward-samenvoegingen: Non-fast-forward-pushes naar specifieke branches voorkomen en zo een lineaire geschiedenis garanderen.
• Het implementeren van fijnmazige toegangscontrole: Bepaalde gebruikers alleen naar specifieke branches laten pushen.
• Het registreren van updates: Elke branch-update vastleggen voor controledoeleinden.
• Het voorkomen van force-pushes: Ervoor zorgen dat de geschiedenis niet wordt herschreven op kritieke branches.

Zo implementeer je hooks aan de serverzijde:

1. Maak verbinding met de server: Je hebt SSH-toegang of iets vergelijkbaars nodig tot de repository op de Git-server.
2. Zoek de map hooks: Ga naar de map .git/hooks binnen je bare repository.
3. Maak of pas scripts aan: Schrijf je hookscript, bijvoorbeeld pre-receive of update.
4. Maak het script uitvoerbaar: Zorg ervoor dat het script uitvoerrechten heeft, bijvoorbeeld chmod +x pre-receive.

Houd er rekening mee dat deze wijzigingen gevolgen hebben voor iedereen die met die repository werkt.

Houd bij het werken met hooks aan de serverzijde rekening met het volgende:

• Houd ze eenvoudig: Complexe logica kan lastig te debuggen en te onderhouden zijn.
• Gebruik versiebeheer voor hooks: Overweeg om je hookscripts in een aparte repository op te slaan en naar je Git-servers te implementeren voor consistentie.
• Test grondig: Zorg ervoor dat je hooks niet per ongeluk legitieme werkstromen blokkeren.
• Let op de prestaties: Hooks worden bij elke push uitgevoerd, dus vermijd bewerkingen die veel bronnen gebruiken.

Ze zijn krachtig, dus gebruik ze verstandig!

Je hebt de kracht van Git-hooks aan de serverzijde verkend! Je hebt geleerd:

• Hooks aan de serverzijde dwingen beleidsregels af op de centrale Git-server.
• pre-receive wordt één keer per push uitgevoerd en is geschikt voor globale controles.
• update wordt één keer per verwijzing uitgevoerd en is geschikt voor fijnmazige controle.
• Voor de implementatie plaats je uitvoerbare scripts in de map hooks van de bare repository.

Deze hooks zijn essentieel voor het behouden van codekwaliteit en een consistente werkstroom in teamomgevingen. Blijf oefenen!