Monorepo und Multirepo: klare Definitionen
| Kriterium | Monorepo | Multirepo |
|---|---|---|
| Projektübergreifende Änderungen | Ein Commit oder PR kann mehrere Projekte umfassen | Meist mehrere Repositories, Versionen und PRs |
| Abhängigkeiten | Leichtere Zentralisierung und gemeinsame Regeln | Mehr Versionsunabhängigkeit |
| CI | Braucht graphbasierte Auswahl, Cache und Skalierung | Kleinerer natürlicher Scope pro Pipeline |
| Zugriff | Pfad-Ownership über Regeln und Reviews | Natürliche Isolation auf Repository-Ebene |
| Tooling | Mehr gemeinsame Standards | Mehr Freiheit pro Projekt |
| Releases | Können unabhängig sein, brauchen Orchestrierung | Natürlich getrennte Pipelines |
Ein Monorepo ist ein Repository mit mehreren logisch getrennten Projekten wie Anwendungen, Services, Bibliotheken oder Werkzeugen. Multirepo, auch Polyrepo genannt, hält diese Elemente in getrennten Repositories. Repository-Grenzen sind Grenzen der Quellcodeverwaltung, nicht automatisch Deployment-Grenzen. [1][13][15]
Ein Monorepo kann daher viele unabhängig deployte Services enthalten, während ein Multirepo-Setup Module eines einzigen großen Systems enthalten kann. Repository-Strategie mit Monolith oder Microservices gleichzusetzen führt zu falschen Architekturentscheidungen.
Was Google Research zeigt: beide Modelle haben echte Vorteile
Google Research fand bei Ingenieuren mit Erfahrung in beiden Modellen die Sichtbarkeit der gesamten Codebasis als wichtigen Monorepo-Vorteil. Sie erleichtert das Finden wiederverwendbarer APIs, vorhandener Beispiele und das Aktualisieren abhängigen Codes bei API-Migrationen. Auch zentrales Dependency Management wurde positiv bewertet. [1]
Dasselbe Paper nennt Vorteile von Multirepo: mehr Freiheit bei Toolchains, stärkere Zugriffskontrollgrenzen und höhere Stabilität zwischen Projekten. Zudem hängt die Erfahrung stark von der Qualität der umgebenden Werkzeuge ab. [1]
Projektübergreifende Änderungen: der klarste Monorepo-Vorteil
Wenn eine Schnittstellenänderung Backend, Frontend, Bibliotheken und Tests gleichzeitig betrifft, kann ein Monorepo die gesamte Migration in einem Commit oder Pull Request enthalten. Google nennt das Aktualisieren abhängigen Codes während API-Migrationen als wichtigen Nutzen eines gemeinsamen Repositorys. [1][2]
In Multirepo wird dieselbe Änderung oft zu einer Abfolge aus Producer-Änderung, Versionierung, Consumer-Updates und mehreren Pull Requests. Automatisierung kann Reibung reduzieren, aber Repository-Grenzen bleiben Prozessgrenzen.
Abhängigkeiten und Versionen: Zentralisierung gegen Unabhängigkeit
Monorepos erleichtern gemeinsame Dependency-Versionen und direkte Referenzen zwischen lokalen Paketen. Yarn Workspaces verbindet Pakete innerhalb eines Projekts, während Constraints Versions- oder `package.json`-Regeln workspaceweit erzwingen können. [13][14]
Multirepo gibt jedem Projekt mehr Freiheit bei Versionen und Upgrade-Zeitpunkten, kann aber zu Drift bei gemeinsamen Bibliotheken führen. Das funktioniert gut, wenn Verträge stabil sind und Artefakte kontrolliert über Registries verteilt werden.
CI im Monorepo: alles bei jedem Commit neu zu bauen ist der falsche Ansatz
Große Monorepos sollten nicht nach jeder Änderung alle Tests und Builds ausführen. Nx `affected` nutzt Git-Historie und Projektgraph, um die kleinste betroffene Projektmenge zu bestimmen und unabhängige Arbeit auszulassen. [4]
Remote Caching teilt bereits berechnete Ergebnisse zwischen Entwicklerrechnern und CI, während verteilte Ausführung übrige Aufgaben auf mehrere Maschinen verteilt. Bazel löst dieselbe Problemklasse mit Remote Execution und Cache für Build- und Testaktionen. [5][7][8]
Multirepo-CI: kleinerer Scope bedeutet nicht keine Koordination
In Multirepo sieht ein einzelner Pipeline-Lauf naturgemäß weniger Code. Dadurch lassen sich Build und Tests leichter auf ein Projekt begrenzen. Das ist ein echter Vorteil bei schwach gekoppelten Services mit klarer Ownership.
Koordinationskosten entstehen bei Abhängigkeiten über Repository-Grenzen. Eine Änderung an gemeinsamer Bibliothek oder Vertrag kann Veröffentlichung, mehrere Repo-Updates, Versionskompatibilität und Integrationstests erfordern. Google nennt Stabilität als Multirepo-Vorteil, aber Sichtbarkeit und Migrationen als Monorepo-Stärken. [1]
Architekturgrenzen: ein Monorepo ohne Regeln wird schnell problematisch
Ein gemeinsames Repository darf nicht unbegrenzte Imports zwischen allen Projekten bedeuten. Nx kann Modulgrenzen über Projekttags und Dependency Constraints deklarativ erzwingen und damit unerwünschte Imports sowie ungeplante Kopplung blockieren. [6]
In Multirepo existieren manche Grenzen physisch durch getrennte Repositories. Das ersetzt jedoch keine Architektur: starke Kopplung kann weiterhin über APIs, Datenbanken, Queues oder gemeinsame Bibliotheken entstehen.
Zugriff und Sicherheit: Multirepo hat oft das einfachere Modell
GitHub vergibt Rollen und Berechtigungen auf Repository-Ebene. Separate Repositories passen deshalb natürlich zu Situationen, in denen Teams oder Auftragnehmer unterschiedliche Codebereiche sehen sollen. Die Rollen reichen von Read bis Admin. [11]
Im Monorepo können CODEOWNERS und Rulesets Reviews für bestimmte Pfade und Teams erzwingen, sind aber Ownership- und Freigabemechanismen. Wenn harte Trennung der Code-Sichtbarkeit nötig ist, passt ein separates privates Repository meist direkter zum Zugriffsmodell. [10][12]
Releases und Deployment: ein Repository bedeutet nicht ein Release
Yarn beschreibt Workspaces als mehrere Pakete in einem Projekt und weist ausdrücklich darauf hin, dass sie unabhängig deployt werden können. Gradle Multi-Project Builds teilen Systeme ebenfalls in logische Subprojekte mit eigenen Abhängigkeiten und Aufgaben. [13][15]
Ein Monorepo kann daher getrennte Pipelines und Versionen für Anwendungen, Services und Bibliotheken haben. Multirepo liefert diese Trennung natürlicher, braucht aber mehr Automatisierung, wenn mehrere Releases als eine Produktänderung koordiniert werden müssen.
Repository-Größe und Git: sehr große Monorepos brauchen gezielte Werkzeuge
Google beschrieb ein internes Monorepo mit Milliarden Codezeilen, betonte aber gleichzeitig die dafür gebaute Infrastruktur. Das Beispiel zeigt, dass Monorepos sehr weit skalieren können, nicht dass diese Skalierung kostenlos oder für jede Firma sinnvoll ist. [2]
Aktuelles Git bietet `sparse-checkout`, um den Working Tree auf einen Teil der verfolgten Dateien zu begrenzen. Das hilft bei großen Repositories, wobei die Git-Dokumentation das Verhalten weiterhin als experimentell und veränderlich bezeichnet. [9]
Werkzeuge 2026 senken die Kosten beider Ansätze
Im JavaScript-Ökosystem gibt es native Workspaces sowie ausgereifte Projektgraphen, Caching und affected-only CI. Im JVM-Ökosystem unterstützt Gradle Multi-Project Builds, während Composite Builds unabhängige Builds zusammenführen und gemeinsame Entwicklung ohne vorherige Artefaktveröffentlichung erlauben. [13][15][16]
Das ist auch für Multirepo wichtig: getrennte Repositories müssen kein vollständig getrenntes lokales Arbeiten bedeuten. Composite Builds zeigen, wie unabhängige Build-Grenzen erhalten und trotzdem gemeinsam getestet werden können. [16]
AI Coding Agents werden 2026 zu einem neuen Entscheidungskriterium
Nx argumentiert in seiner Dokumentation von 2026, dass Coding Agents von vollständigem Monorepo-Kontext, Projektgraph, schneller affected-only Verifikation und erzwungenen Grenzen profitieren. Da Nx ein Monorepo-Tooling-Anbieter ist, ist dies eine Produktperspektive und kein unabhängiger Beweis. [3]
Gemeinsamer Kontext kann einem Agenten praktisch helfen, einen Vertrag und seine Consumer in einer Aufgabe zu ändern. Multirepo kann dagegen den verfügbaren Code- und Berechtigungsumfang einer Agentensitzung stärker begrenzen. Das ist ein zusätzliches Kriterium, kein alleiniger Entscheidungsgrund.
Wann Monorepo sinnvoll ist
Monorepo passt besonders gut, wenn Anwendungen und Bibliotheken häufig gemeinsam geändert werden, viele Teams Komponenten teilen und atomare Refactorings sowie ein sichtbarer Abhängigkeitsgraph wichtig sind. Google Research unterstützt diese Vorteile durch Sichtbarkeit, API-Discovery, Nutzungsbeispiele, Migrationen und zentrale Abhängigkeiten. [1]
Voraussetzung sind Investitionen in Modulgrenzen, selektives CI, Caching, Code Ownership und Automatisierung. Ohne diese Kontrollen verschiebt ein wachsendes Repository die Komplexität nur in eine riesige Pipeline. [4][5][6]
- Häufige Änderungen über Frontend, Backend und Bibliotheken hinweg.
- Viel gemeinsam genutzter Code und gemeinsame Engineering-Standards.
- Bedarf an atomaren Refactorings.
- Einheitliche oder kompatible Toolchain.
- Bereitschaft für Dependency Graph, Cache und selektives CI.
- Keine harte Anforderung, internen Teams den größten Teil des Codes zu verbergen.
Wann Multirepo sinnvoll ist
Multirepo ist stark, wenn Domains klare Grenzen haben, Teams unabhängige Toolchains, Lebenszyklen und Berechtigungen brauchen und projektübergreifende Änderungen selten sind. Google Research nennt Tool-Flexibilität, Zugriffskontrolle und Stabilität als relevante Vorteile. [1]
Ein weiteres Signal sind eingeschränkte Code-Sichtbarkeit, separate Compliance-Anforderungen oder unterschiedliche Auftragnehmergruppen. GitHubs Repository-Rollen unterstützen diese Trennung direkt. [11]
- Starke Teamautonomie und getrennte Lebenszyklen.
- Unterschiedliche Sprachen, Toolchains und Build-Prozesse.
- Strikte Zugriffs- oder Compliance-Anforderungen.
- Seltene Änderungen über viele Projekte hinweg.
- Stabile Verträge und reifes Versionsmanagement.
- Unabhängige Pipelines sind wichtiger als ein gemeinsamer Plattformgraph.
Hybridmodell und praktische Entscheidung 2026
| Situation | Standardrichtung | Warum |
|---|---|---|
| Häufige Änderungen über mehrere Apps und Bibliotheken | Monorepo | Atomare Refactorings und gemeinsamer Abhängigkeitsgraph |
| Teams dürfen nicht den gesamten Code sehen | Multirepo | Repository-Berechtigungen vereinfachen Isolation |
| Teams brauchen verschiedene Toolchains und Lebenszyklen | Multirepo | Weniger zentrale Standardisierung |
| Stark geteilte Plattform und Bibliotheken | Monorepo | Bessere Sichtbarkeit und zentrale Abhängigkeiten |
| Viele kleine Services | Kommt darauf an | Häufigkeit gemeinsamer Änderungen ist wichtiger als Service-Anzahl |
| Gemischte Domain-, Zugriffs- und Technologieanforderungen | Hybrid | Domain-Monorepos plus ausgewählte separate Repositories |
Die Wahl muss nicht binär sein. Eine Organisation kann Domain-Monorepos für eng gekoppelte Produkte, separate Repositories für sicherheitskritische oder kundenspezifische Komponenten und gemeinsame Pakete über Registries kombinieren. Gradle Composite Builds zeigen sogar technisch, wie unabhängige Builds gemeinsam entwickelt werden können. [16]
Vor einer Migration sollten Häufigkeit projektübergreifender Änderungen, Anzahl gemeinsamer Abhängigkeiten, CI-Dauer, Zahl der Repositories pro typischem Feature, Zugriffsanforderungen und Release-Koordinationskosten gemessen werden. Diese Daten sollten die Repository-Topologie bestimmen.
