- Els Git Hooks són scripts que s'executen automàticament davant d'esdeveniments com a commits o pushes per validar el codi.
- Es distingeixen hooks de client, per a rapidesa local, i hooks de servidor, per a regles obligatòries dequip.
- La gestió professional de hooks requereix eines com Husky o la configuració de core.hooksPath per compartir-los a l'equip.
- La seva integració amb fluxos de CI/CD permet desplegaments web automatitzats i una reducció dràstica derrors manuals.
Imagina que poguessis tenir un assistent personal que revisés cada línia del teu codi, comprovés que els missatges de commit no són un desastre i llencés les proves unitàries just abans que pugis els canvis al servidor, tot sense que hagis de moure un dit. Doncs bé, això és exactament el que fan els Git Hooks , aquests petits scripts que es queden a l'aguait al teu repositori per automatitzar tasques tedioses i evitar que fiquis la pota en el moment menys oportú.
Ja sigui que treballis només en un projecte personal o que formis part d'un equip gran, integrar aquestes automatitzacions al Git for Windows és un salt de qualitat brutal. No es tracta només d?estalviar temps, sinó d? estandarditzar el flux de treball perquè el codi sigui net, consistent i, sobretot, lliure d?errors evitables abans que arribin a la branca principal.
Quins dimonis són els Git Hooks i com funcionen?
En essència, els hooks són guions personalitzats que Git dispara automàticament quan passa un esdeveniment específic al cicle de vida del desenvolupament. Pensa en ells com a disparadors d'esdeveniments : quan fas un commit, un push o un merge, Git mira si hi ha un script corresponent a la carpeta de configuració i, si n'hi ha, ho executa. Si l'script torna un error (un codi de sortida 1), Git bloqueja l'operació , obligant-vos a corregir el problema abans de seguir.
Aquests scripts es guarden en una zona oculta del teu projecte, concretament al directori .git/hooks . En crear un repositori, Git ja et deixa unes quantes plantilles amb l'extensió .sample perquè no comencis de zero. Només has de reanomenar-les, treure'ls aquesta extensió i afegir-los la teva pròpia lògica, ja sigui usant Bash, Python o Ruby, sempre que el sistema pugui executar-los.
Tipus de ganxos: Quina triar segons el moment?
Per no embolicar-nos, és fonamental distingir entre els hooks que viuen al teu ordinador (costat del client) i els que resideixen al servidor remot.
Hooks del costat del client
Aquests són els més comuns per al dia a dia del desenvolupador, ja que permeten detectar errors a l'instant sense esperar que el servidor de CI/CD ens renyi:
- precompromís: És el guardià del codi. Es llança abans que es creï el commit. És ideal per executar linters o formatadors com Prettier o ESLint, assegurant que ningú no pugi codi amb indentacions rares o errors de sintaxi.
- prepare-commit-msg: Útil per emplenar automàticament el missatge del commit, afegint, per exemple, el número de la tasca de Jira o el nom de la branca.
- commit-msg: Aquest s'encarrega que el missatge sigui descriptiu. Pots forçar que segueixin la metodologia de Conventional Commits (usant prefixos com a feat: o fix:), evitant els clàssics missatges tipus «canvis diversos» que no diuen res.
- post-commit: S'executa després de confirmar els canvis. Serveix per llançar notificacions o actualitzar documentació local.
- pre empenta: És l'última línia de defensa. Executa proves més exhaustives abans d'enviar el codi al remot, evitant que trenques la build dels teus companys.
- post-checkout i post-merge: Ideals per actualitzar submòduls o netejar caixets de l'entorn cada vegada que canvies de branca o fusiones codi.
Hooks del costat del servidor
Aquests es configuren al repositori bare del servidor i són obligatoris per a tot l'equip, ja que no es poden saltar amb l'ordre –no-verify:
- pre-receive: Valida que el push compleixi regles estrictes abans d'acceptar-lo al servidor.
- actualització: Similar a l'anterior, però s'executa una vegada per cada branca actualitzada.
- post-receive: El rei de l'automatització. S'usa per desplegar el codi automàticament al servidor web o enviar alertes a Slack informant que hi ha canvis nous.
Guia pas a pas per muntar el teu primer Hook
Si vols començar ja mateix a Windows, el procés és força senzill. Primer, navega fins a la carpeta .git/hooks del teu projecte. Si vols activar un precommit, crea un fitxer anomenat exactament així, sense cap extensió. Perquè Git ho reconegui, t'has d'assegurar que sigui executable; en sistemes basats en Unix o usant Git Bash a Windows, l'ordre és chmod +x .git/hooks/pre-commit.
Un cop creat, obre el fitxer amb el teu editor favorit i afegeix el shebang al principi (per exemple, #!/bin/bash) per dir-li al sistema quin intèrpret utilitzar. Tot seguit, escriu la lògica. Per exemple, si utilitzes PHP, podries integrar PHP CodeSniffer perquè el commit falli si l'estil no és correcte. Recordeu que si l'script acaba amb exit 0, l'operació segueix endavant, però si s'acaba amb exit 1, Git aturarà el procés immediatament.
Integració amb CI/CD i desplegament web
Encara que els hooks són potents, no han de substituir una plataforma d' Integració Contínua i Lliurament Contínu (CI/CD) com ara Jenkins, GitHub Actions o GitLab CI, sinó complementar-la. L'estratègia ideal és un enfocament híbrid : utilitza hooks locals per a validacions ràpides (linting, tests unitaris simples) i deixa que la plataforma de CI/CD s'encarregue de les proves pesades, la compilació i el desplegament en entorns de staging i producció.
Per automatitzar un desplegament web bàsic, podeu configurar un hook post-receive al vostre servidor. L'script podria executar una ordre git checkout -f cap a la carpeta on resideix la teva web i després reiniciar el servidor Nginx o Apache. Això redueix els errors manuals en un percentatge altíssim i permet que les actualitzacions arribin a producció a qüestió de minuts.
Trucs per no tornar boig amb els Hooks
Hi ha un problema: la carpeta .git no s'enfila al repositori, per la qual cosa els hooks són locals i cada desenvolupador els hauria de configurar a mà. Per evitar aquest caos, hi ha dues solucions principals. La primera és crear una carpeta pròpia al projecte (com .githooks), pujar-la al repo i executar l'ordre git config core.hooksPath .githooks per dir-li a Git que busqui els scripts allà.
La segona opció, i potser la més professional, és fer servir eines com Husky (per a Node.js) o el framework pre-commit . Aquestes eines permeten definir els hooks en un fitxer YAML, facilitant que tot l'equip tingui la mateixa configuració de forma automàtica en instal·lar les dependències del projecte.
Això sí, vés amb compte de no passar-te de la ratlla. Si creeu hooks massa pesats que triguin minuts en executar-se, els desenvolupadors acabaran odiant-los i començaran a usar –no-verify per saltar-los. Mantingues els scripts lleugers, documenta bé què fa cadascú al README i prioritza la velocitat perquè l'eina sigui una ajuda i no un destorb.
Avantatges, riscos i millors pràctiques
Implementar aquesta metodologia aporta beneficis clars: es redueix la quantitat de bugs que arriben al servidor, el codi és molt més homogeni i l'equip gasta menys temps en revisions manuals superficials . Tot i això, hi ha el risc de generar una dependència excessiva de l'entorn local o d'introduir scripts insegurs que exposin credencials si no es gestionen bé mitjançant variables d'entorn.
Per evitar problemes, el més intel·ligent és modularitzar els pipelins, separant la compilació, les proves i el desplegament. Implementar estratègies de desplegament blue-green juntament amb hooks de servidor permet canviar el trànsit de manera fluida i tornar enrere ràpidament si falla alguna cosa, minimitzant el temps d'inactivitat.
Tenir el control total dels esdeveniments de Git mitjançant scripts personalitzats permet que el flux de desenvolupament sigui molt més fluid i segur, eliminant el factor de lerror humà en tasques repetitives. Combinant la rapidesa dels hooks locals amb la robustesa d'un servidor de CI/CD i eines de gestió com Husky, qualsevol equip pot garantir que només el codi que compleix els estàndards més estrictes arribi a producció, optimitzant així la productivitat i la qualitat final del programari.