Git-Repository-Struktur: Meine Blaupause für skalierbare Monorepos und Polyrepos.

Git-Struktur: Monorepo vs. Polyrepo – Die richtige Wahl für Ihr Team

Die Frage nach der optimalen Repository-Struktur wird in Entwicklerteams oft fast religiös diskutiert. Sollten alle Services eines Projekts in einem einzigen, großen “Monorepo” liegen, oder verdient jeder Microservice sein eigenes “Polyrepo”? Eine falsche Entscheidung kann zu massiven Problemen bei der CI/CD-Geschwindigkeit, dem Dependency-Management und der Team-Kollaboration führen. In diesem Beitrag präsentiere ich meine Blaupause für skalierbare Git-Strukturen.

1. Das Polyrepo-Modell: Isolation und Unabhängigkeit

Das Polyrepo-Modell ist der klassische Ansatz für Microservices. Jeder Dienst hat sein eigenes Git-Repository.

• Vorteile: Klare Ownership, isolierte CI/CD-Pipelines (eine Änderung an Service A startet keine Tests für Service B) und einfache Zugriffssteuerung.
• Herausforderungen: Shared Code (Libraries) muss über Paketmanager (NPM, Go Modules) versioniert werden. Dies kann zu “Dependency Hell” führen, wenn verschiedene Services unterschiedliche Versionen derselben Library nutzen.

2. Das Monorepo-Modell: Konsistenz und atomare Commits

In einem Monorepo liegen alle Services und geteilten Bibliotheken in einem einzigen Repository, meist strukturiert durch Tools wie Nx (für Angular/JS) oder Go Workspaces.

• Vorteile: Atomare Refactorings über Service-Grenzen hinweg sind möglich. Man sieht sofort, wenn eine Änderung an einer Core-Library einen Service bricht. Dependency-Management ist deutlich einfacher, da alle Services dieselbe Version einer Library nutzen.
• Herausforderungen: Die CI/CD-Pipeline muss intelligent sein (“Affected-Builds”), um nicht bei jeder kleinen Änderung alles neu zu bauen. Git-Operationen können bei extrem großen Repos (wie bei Google oder Meta) langsam werden.

3. Meine Blaupause: Der “Domain-Driven” Ansatz

Ich empfehle oft einen hybriden Weg, der sich an fachlichen Domänen orientiert.

• Struktur: Anstatt eines gigantischen Unternehmens-Monorepos erstelle ich pro fachlicher Domäne (z.B. “E-Commerce”, “Logistik”) ein Monorepo.
• Nutzen: Innerhalb der Domäne genießen wir alle Vorteile der atomaren Commits und des einfachen Dependency-Sharings. Die Kopplung zwischen den Domänen bleibt lose und erfolgt über stabile APIs.

4. Durchsetzung der Struktur: Git-Policies und Tooling

Eine Struktur ist nur so gut wie ihre Einhaltung.

• CODEOWNERS: Ich nutze CODEOWNERS Dateien, um automatisch die richtigen Reviewer für bestimmte Unterordner zuzuweisen.
• Branch-Protection: Strenge Regeln für den Main-Branch (keine Pushes ohne Review, nur grüne CI-Builds).
• Linter für die Struktur: Automatisierte Checks stellen sicher, dass keine unerlaubten Abhängigkeiten zwischen Projekten innerhalb des Monorepos entstehen (z.B. darf eine Library nicht von einem Service abhängen).

Fazit: Es gibt keine “Silver Bullet”

Die Wahl zwischen Monorepo und Polyrepo hängt von der Teamgröße, der technischen Reife und der Architektur der Anwendung ab. Kleine, agile Teams profitieren oft von der Geschwindigkeit eines Monorepos. Große Organisationen mit hunderten Entwicklern benötigen oft die Isolation von Polyrepos oder domänenspezifischen Monorepos. Wichtig ist, dass die Entscheidung bewusst getroffen und durch das richtige Tooling unterstützt wird.

Stehen Sie vor der Entscheidung für eine neue Git-Strategie oder kämpfen Sie mit den Nachteilen Ihrer aktuellen Struktur?
Ich unterstütze Sie bei der Planung und Migration Ihrer Repository-Landschaft und der Optimierung Ihrer CI/CD-Prozesse. Lassen Sie uns Ihre Git-Strategie gemeinsam optimieren.