Realidades del monorepo

Un monorepo alberga muchos proyectos en un repositorio — mejores refactores, cambios atómicos cross-proyecto, un solo grafo de dependencias. El costo: escala. Los repos pueden crecer a gigabytes y millones de archivos, donde Git ingenuo se vuelve doloroso.

El stack de rendimiento

• Sparse checkout (modo cono): hacer checkout solo de los directorios en los que trabajas.
• Sparse index: saltar rutas no-sparse en el índice por completo (Git 2.37+).
• Partial clone: traer blobs de forma perezosa, bajo demanda.
• Commit-graph + filtros Bloom: log/blame rápidos en subconjuntos.
• Fsmonitor: git status O(1) vía eventos del SO.
• Mantenimiento en background: mantener gc, repacking e índices frescos.

Setup de un golpe

git clone --filter=blob:none --sparse https://example.com/big.git
cd big
git sparse-checkout init --cone --sparse-index
git sparse-checkout set apps/web libs/ui
git config feature.manyFiles true
git config core.fsmonitor true
git config core.untrackedCache true
git maintenance start

CODEOWNERS y protección de branches

Los monorepos confían en propiedad por directorio. Combina archivos CODEOWNERS de GitHub/GitLab con reviews requeridas.

CI consciente de rutas

changed=$(git diff --name-only origin/main..HEAD | cut -d/ -f1 | sort -u)
for pkg in $changed; do
  [ -f "$pkg/Makefile" ] && make -C "$pkg" test
done

Capa de tooling

Orquestadores de build (Bazel, Buck2, Pants, Nx, Turborepo) consumen el diff y re-ejecutan solo los targets afectados.

Errores comunes

Tratar un monorepo como un repo pequeño y saltarse las optimizaciones. Olvidar que los tiempos de git status incluyen trabajo del kernel; fsmonitor lo resuelve.