Monorepo: Viele Projekte in einem Repository

Kurz: Mehrere zusammengehörige Programme und Bibliotheken liegen gemeinsam in einem einzigen Git-Repository statt in vielen getrennten.

Genauer: Beim Monorepo haben Frontend, Backend, gemeinsame Bibliotheken und Werkzeuge ein gemeinsames Repository, aber meist eigene Ordner und Pakete. Große Firmen wie Google oder Meta arbeiten so, und im JavaScript-Umfeld ist es mit Werkzeugen wie pnpm-Workspaces, Nx oder Turborepo verbreitet. Das Gegenstück ist das Polyrepo, bei dem jedes Projekt ein eigenes Repository hat.

Im Detail

Struktur

meine-firma/
  apps/
    web/
    api/
  packages/
    ui/            gemeinsame Bausteine
    config/
  package.json     Workspace-Konfiguration

Die Pakete verweisen mit lokalen Abhängigkeiten aufeinander, ein Befehl installiert alles.

Vorteile

• Atomare Änderungen: Eine Änderung an einer Bibliothek und allen Nutzern lässt sich in einem Commit und Pull Request erledigen.
• Gemeinsame Werkzeuge: ein Lint- und Testsetup, eine Versionsstrategie.
• Einfaches Teilen von Code ohne Veröffentlichung von Paketen.
• Überblick: alles an einem Ort, leicht zu durchsuchen.

Nachteile und Gegenmittel

Das Repository wird groß, und naive Pipelines bauen bei jeder Änderung alles neu. Moderne Werkzeuge bauen nur Betroffenes (Abhängigkeitsgraph) und nutzen einen Build-Cache, auch gemeinsam im Team. Zugriffsrechte lassen sich schwerer pro Projekt trennen, dafür helfen Code-Owner-Dateien (CODEOWNERS). Sehr große Repositories brauchen Git-Funktionen wie Sparse Checkout.

Entscheidung

Für ein kleines Team mit zusammengehörigen Teilen ist ein Monorepo oft bequemer. Sind Projekte unabhängig, haben getrennte Teams und Release-Zyklen, kann ein Polyrepo sinnvoller sein. Ein Monorepo ist nicht dasselbe wie ein Monolith: Auch dort können Dienste getrennt gebaut und ausgeliefert werden.

Siehe auch: Git, CI/CD-Pipeline, SemVer, Modularer Monolith