Monorepo-Realitaten

Ein Monorepo halt viele Projekte in einem Repository — bessere Refactors, atomare projektubergreifende Anderungen, ein einziger Abhangigkeitsgraph. Die Kosten: Skalierung.

Der Performance-Stack

• Sparse Checkout (Cone-Modus).
• Sparse Index (Git 2.37+).
• Partial Clone.
• Commit-Graph + Bloom-Filter.
• Fsmonitor.
• Background Maintenance.

One-Shot-Setup

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 und Branch-Schutz

Monorepos verlassen sich auf Owner pro Verzeichnis.

Pfad-bewusste CI

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

Tooling-Schicht

Build-Orchestratoren (Bazel, Buck2, Pants, Nx, Turborepo) konsumieren das Diff und fuhren nur betroffene Targets erneut aus.

Haufige Fehler

Ein Monorepo wie ein kleines Repo behandeln und die Optimierungen uberspringen.