Réalités du monorepo

Un monorepo héberge plusieurs projets dans un dépôt — meilleurs refactors, changements atomiques cross-projets, un seul graphe de dépendances. Le coût : l'échelle. Les repos peuvent croître à des gigaoctets et des millions de fichiers, où Git naïf devient pénible.

La pile de performance

• Sparse checkout (mode cône).
• Sparse index (Git 2.37+).
• Partial clone.
• Commit-graph + filtres Bloom.
• Fsmonitor.
• Background maintenance.

Setup en un coup

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 et branch protection

Les monorepos s'appuient sur la propriété par répertoire.

CI conscient des chemins

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

Couche de tooling

Les orchestrateurs de build (Bazel, Buck2, Pants, Nx, Turborepo) consomment le diff et ne relancent que les targets affectés.

Erreurs courantes

Traiter un monorepo comme un petit repo et sauter les optimisations.