Monorepo vs Polyrepo: die richtige Repo-Struktur

Die Monorepo-Polyrepo-Debatte taucht auf, sobald ein Projekt zu wachsen beginnt. Hältst du deinen gesamten Code in einem einzigen Git-Repository, oder teilst du jeden Service, jedes Paket oder jede App in ein eigenes Repo auf? Es gibt keine universelle "Mach es immer so"-Antwort; es hängt von deiner Teamgröße, deinem Deploy-Modell und deinem Tooling ab. In diesem Artikel vergleiche ich beide Ansätze mit konkreten Beispielen und zeige dir, wie du entscheidest, welcher in deinem eigenen Projekt weniger weh tut.

Die Grundlagen: Was sind Monorepos und Polyrepos?

Ein Monorepo ist ein einzelnes Versionskontroll-Repository, das mehrere Projekte, Pakete oder Services enthält. Frontend, Backend, gemeinsame Bibliotheken und Infrastrukturskripte kommen alle mit einem einzigen git clone. Ein typisches Layout sieht so aus:

my-company/
├── apps/
│   ├── web/
│   └── admin/
├── packages/
│   ├── ui/
│   └── config/
└── services/
    └── api/

Ein Polyrepo (Multi-Repo) hält ein separates Git-Repository pro unabhängiger Einheit: company-web, company-api, company-ui-kit und so weiter. Jedes Repo trägt seine eigene Versionierung, seine eigene CI-Pipeline und seine eigenen Zugriffsrechte. Beide Ansätze werden seit Jahren produktiv eingesetzt; die eigentliche Frage ist, welcher zu deinen Rahmenbedingungen passt.

Wo Monorepos glänzen

Der größte Reiz eines Monorepos ist, dass es eine einzige Quelle der Wahrheit bietet. Wenn du eine gemeinsame Komponente änderst, kannst du jede App, die sie nutzt, im selben Commit aktualisieren. Das bedeutet atomare Änderungen:

• Konsistente Abhängigkeiten: Alle Projekte verwenden dieselben Bibliotheksversionen, sodass "bei mir lief es"-Probleme abnehmen.
• Einfaches Code-Teilen: Du importierst ein gemeinsames ui-Paket direkt, ohne ein neues Repo zu veröffentlichen.
• Übergreifende Refactorings: Beim Umbenennen eines API-Feldes korrigierst du sowohl den Server als auch alle Clients in einem einzigen Pull Request.
• Sichtbarkeit: Mit allem Code an einem Ort werden Suchen, Navigieren und das Festlegen von Standards einfacher.

Für eng gekoppelte Codebasen, die sich häufig gemeinsam ändern, erzeugt ein Monorepo meist weniger Reibung.

Wo Polyrepos glänzen

Polyrepos setzen auf klare Grenzen und Unabhängigkeit. Jedes Team besitzt sein eigenes Repo, seinen eigenen Release-Rhythmus und seinen eigenen Deploy-Zeitplan. Die Vorteile sind:

• Kleinere Oberfläche: Ein Entwickler klont nur das Repo, das ihn betrifft, sodass Checkout und Indizierung schnell bleiben.
• Unabhängige Versionierung: Jeder Service taggt seine eigene semantische Version; das Release eines Teams wartet nicht auf ein anderes.
• Feingranularer Zugriff: Nur autorisierte Personen erreichen das Repo eines sensiblen Services.
• Einfache CI: Die Pipeline jedes Repos baut nur dieses Repo, ohne zusätzliche Logik, um herauszufinden, "was sich geändert hat".

Für Services, die wirklich unabhängig sind, in verschiedenen Sprachen geschrieben oder auf unterschiedlichen Lebenszyklen laufen, fließt ein Polyrepo ganz natürlich.

Skalierung und der Einfluss des Toolings

Was die Frage meist entscheidet, ist das Tooling. Während ein Monorepo wächst, werden naive Setups langsam: Du willst nicht bei jedem Commit alles neu bauen. Deshalb stützen sich Monorepos meist auf einen Task-Runner. Im JavaScript/TypeScript-Ökosystem sind turborepo, nx und pnpm Workspaces verbreitet; sie bauen nur die betroffenen Pakete und cachen die Ergebnisse.

# pnpm-Workspace-Definition
# pnpm-workspace.yaml
packages:
  - "apps/*"
  - "packages/*"

In einem Polyrepo verlagert sich das Problem: Builds bleiben einfach, aber das Abhängigkeitsmanagement wird schwieriger. Du musst die gemeinsame Bibliothek in einer Paket-Registry veröffentlichen (zum Beispiel einer privaten npm-Registry oder einem Composer/Packagist-Setup für PHP) und danach die Version in jedem konsumierenden Repo erhöhen. Das erhöht das Risiko von Versionsabweichungen (Version Skew): Repo A nutzt vielleicht Bibliothek 2.1, während Repo B noch auf 1.8 ist.

Welches solltest du wählen?

Ein praktischer Entscheidungsrahmen:

• Bevorzuge ein Monorepo, wenn du ein kleines bis mittleres Team bist, deine Codebasen eng gekoppelt sind, du häufig übergreifende Änderungen machst und du bereit bist, in ein Werkzeug wie nx oder turborepo zu investieren.
• Bevorzuge ein Polyrepo, wenn du mehrere unabhängige Teams hast, deine Services in verschiedenen Sprachen und Lebenszyklen laufen, du strikte Zugriffstrennung brauchst und du lose Kopplung über klare API-Verträge willst.

Es gibt einen dritten Weg: einen schrittweisen Mittelweg. Viele Teams bündeln einige verwandte Services in einem Monorepo und halten völlig getrennte Produkte auseinander. Du musst nicht "rein" sein; ziehe die Grenze danach, wie oft sich der Code gemeinsam ändert.

Häufig gestellte Fragen

Verlangsamt ein Monorepo Git?

Bei sehr großer Historie kann das passieren, aber für die meisten Projekte ist es kein Problem. Wenn das Repo wirklich riesig wird, kannst du einen Partial Clone mit git clone --filter=blob:none oder Sparse-Checkout verwenden, um nur die benötigten Ordner zu holen.

Brauche ich ein Polyrepo, wenn ich Microservices nutze?

Nein. Architektur (Microservices) und Repo-Struktur (Mono/Poly) sind unabhängige Entscheidungen. Große Teams halten Dutzende Microservices in einem einzigen Monorepo; unabhängiges Deployen bleibt möglich.

Kann ich später von einem zum anderen migrieren?

Ja. Mit git subtree oder git filter-repo kannst du Repositories unter Beibehaltung der Historie zusammenführen oder aufteilen. Die Migration ist nicht kostenlos, aber machbar; überlade also die anfängliche Entscheidung nicht.

Lass uns gemeinsam die richtige Struktur für dein Projekt bestimmen. Wir können deine bestehenden Repos, deine CI-Pipeline und deinen Team-Workflow durchgehen und danach das Monorepo- oder Polyrepo-Layout aufsetzen, das zu dir passt. Nimm Kontakt auf und lass uns über deine Anforderungen sprechen.