Guía por archivo
Hooks de git al clonar: cuándo se activan de verdad
Los hooks de git son scripts que git ejecuta en momentos fijos: antes de un commit, después de un checkout, antes de un push. La duda habitual es si clonar un repositorio ya los deja activos. La respuesta corta es que no, pero casi siempre hay un paso que los conecta.
Lo medimos
de los 9,997 repositorios más populares de GitHub tienen al menos un hallazgo de la familia git.
repositorios con hooks versionados, core.hooksPath o entradas locales de pre-commit.
Qué se ejecuta y cuándo
Un git clone normal no copia la carpeta .git/hooks del remoto: crea la tuya a partir de las plantillas locales. Los hooks que vienen con el proyecto viven en carpetas versionadas como .husky/, .githooks/ o en .pre-commit-config.yaml, y no hacen nada hasta que alguien los conecta.
Ese paso suele ser automático. Con husky, el script prepare de package.json configura core.hooksPath en cuanto haces npm install. Con pre-commit, basta con pre-commit install, y las entradas con repo: local ejecutan el comando que el proyecto quiera. Con .githooks/, un script de setup o una línea del README te pide git config core.hooksPath .githooks. Desde ese momento, cada commit o checkout ejecuta código del repositorio.
Hay un caso en que los hooks sí llegan vivos: cuando el proyecto te llega como archivo comprimido o carpeta copiada que incluye su .git. Entonces .git/hooks y .git/config son los del autor, y git status o un commit pueden ejecutarlos.
Lo que ya ha pasado
Según Elastic, la vulnerabilidad CVE-2025-48384 de Git en Linux y macOS permitía que un git clone --recursive de un repositorio preparado terminara ejecutando un script a través de un submódulo y un hook. Está corregida en las versiones actuales de Git: actualiza si clonas de forma recursiva.
En nuestro estudio, 987 de los 9,997 repositorios más populares (9.9%) tienen al menos un hallazgo de hooks de git. Casi todos son linters y formateadores legítimos, que es justo el disfraz más cómodo.
Cómo revisarlo a mano
Mira si el clon ya tiene un core.hooksPath configurado y si hay hooks que no sean las muestras .sample. Lee las carpetas versionadas antes de instalar, y en .pre-commit-config.yaml fíjate en las entradas repo: local.
Si el proyecto llegó con su propia carpeta .git, revisa también .git/config: claves como core.fsmonitor también ejecutan comandos.
git config --show-origin --get-regexp 'core\.(hookspath|fsmonitor)'ls .git/hooks | grep -v '\.sample$'ls -la .husky .githooks 2>/dev/null; grep -n -A4 'repo: local' .pre-commit-config.yaml 2>/dev/nullQué marca Onopen
El escáner githooks lee las rutas de hooks de git y .pre-commit-config.yaml. Marca un core.hooksPath redirigido, los hooks vivos en el clon, los scripts versionados que esperan a que alguien los conecte y las entradas locales de pre-commit. Como dependen de un acto tuyo, como hacer commit, suelen salir como diferidos (~).
onopen --only githooks,packages --explain ./repoPreguntas frecuentes
¿git clone ejecuta hooks del repositorio?
Un clon normal no: no copia .git/hooks. Pero herramientas como husky o pre-commit los activan al instalar dependencias o con un comando de setup.
¿Qué es core.hooksPath?
Una opción de git que cambia la carpeta de la que se leen los hooks. Si apunta a una carpeta del repositorio, todo lo que haya ahí se ejecuta en cada evento.
¿Cómo hago commit sin ejecutar hooks?
git commit --no-verify salta pre-commit y commit-msg. Para el resto, revisa o quita core.hooksPath antes de trabajar.
Fuentes
Otras guías
Revisa un repositorio antes de abrirlo
Onopen es gratis y de código abierto. Lee la configuración, no ejecuta nada y no abre ninguna conexión.