// workshop equipo de dev

Por qué usar pre-commit hooks

Cada razón, con su receta. Sales convencido y con tu primer hook cuidando el repo.
el problema

El CI te tira en rojo lo obvio

  • ✕Formato y lint que fallan en el CI, después de pushear.
  • ✕Commits "arreglo el linter", "ahora sí el formato".
  • ✕Un .env o una API key que se cuela al repo.
Un hook corre esos checks antes del commit, en tu máquina, en segundos.
analogía
El hook es el portero. Nada entra al repo sin pasar el control.
// arreglas el formato antes de commitear, no cuando el CI te lo tira
el portero

Un control antes de cada commit

  • →Git hook: un script que git dispara en ciertos momentos.
  • →pre-commit: el framework que los gestiona, multi-lenguaje.
  • →Se configuran en un solo .pre-commit-config.yaml.
Se comitea al repo: todo el equipo tiene los mismos checks.
$_
manos a la obra

Tu primer hook

Instalar, configurar, y ya cuida cada commit.
dos comandos

Instala y engancha

$ pip install pre-commit # o brew install pre-commit
$ pre-commit install # lo engancha a git
A partir de acá, cada git commit dispara los hooks configurados.
cero discusión

Todo el equipo, el mismo estilo

# .pre-commit-config.yaml
repos:
- repo: https://github.com/astral-sh/ruff-pre-commit
rev: v0.6.0
hooks:
- id: ruff-format
- id: ruff
Cada commit queda formateado y linteado. Nadie discute estilo en los PRs.
analogía
Formateas antes de commitear, no cuando el CI te lo tira en rojo.
// segundos en tu máquina en vez de minutos de ida y vuelta con el CI
nada se filtra

Un hook que huele credenciales

- repo: https://github.com/gitleaks/gitleaks
rev: v8.18.0
hooks:
- id: gitleaks
Si un .env o una API key intenta entrar, el commit se detiene. Antes de que sea tarde.
local = ci

El mismo control en los dos lados

$ pre-commit run --all-files # todo el repo
# en GitHub Actions
- uses: pre-commit/action@v3.0.1
El CI corre exactamente los hooks que tú. Nada pasa por un lado y falla por el otro.
la trampa

Rápido, o nadie lo usa

  • ·El pre-commit debe ser rápido: formato, lint, secretos.
  • ·Tests lentos o build pesado frenan cada commit: eso va al CI.
  • ·Un commit que tarda 30 segundos, la gente lo saltea.
Regla: si tarda más de un par de segundos, no va en pre-commit.
la letra chica

Casi siempre suma

  • ·Ideal en cualquier repo con más de una persona.
  • ·El dev puede saltearlo con --no-verify: por eso el CI también corre.
  • ·No reemplaza al CI, lo adelanta.
El hook atrapa temprano; el CI es la red final. Los dos, no uno.
el lunes

Engancha pre-commit en un repo

01pip install pre-commit y pre-commit install.
02Agrega un .pre-commit-config.yaml.
03Hook de formato + lint de tu lenguaje.
04Hook de secretos (gitleaks).
05pre-commit run --all-files una vez.
06Corre los mismos hooks en el CI.
cierre

Atrapa temprano, no en el CI

Formato, lint y secretos, resueltos antes del commit. Engancha pre-commit en un repo esta semana.
seguimos en contacto

Sígueme

# notas técnicas y proyectos
web dev.jotive.com.co
# instagram
ig @jotive.dev
A · 01 Por qué usar pre-commit hooks · workshop ← → 01 / 14