it-swarm.com.de

Wählen Sie zwischen einzelnen oder mehreren Projekten in einem Git-Repository?

In einer git Umgebung, in der wir die meisten Projekte modularisiert haben, stehen wir vor dem Projekt pro Repository oder mehrere Projekte pro Repository Designproblem. Betrachten wir ein modularisiertes Projekt:

myProject/
   +-- gui
   +-- core
   +-- api
   +-- implA
   +-- implB

Heute haben wir ein Projekt pro Repository . Es gibt Freiheit zu

  • release einzelne Komponenten
  • tag einzelne Komponenten

Es ist aber auch umständlich, branch Komponenten zu verwenden, da das Verzweigen von api äquivalente Verzweigungen in core und möglicherweise anderen Komponenten erfordert.

Wenn wir einzelne Komponenten release möchten, können wir dennoch die gleiche Flexibilität erhalten, indem wir ein Projekt mit mehreren Projekten pro Repository verwenden.

Welche Erfahrungen gibt es und wie/warum haben Sie diese Probleme angegangen?

239
Johan Sjöberg

one project per repository Hat drei Hauptnachteile, wie Sie es oben beschrieben haben. Diese sind weniger wahr, wenn es sich um wirklich unterschiedliche Projekte handelt, aber von den Klängen her erfordern Änderungen an einem oft Änderungen an einem anderen, was diese Probleme wirklich übertreiben kann:

  1. Es ist schwieriger zu erkennen, wann Fehler eingeführt wurden. Tools wie git bisect Werden viel schwieriger zu verwenden, wenn Sie Ihr Repository in Unter-Repositorys aufteilen . Es ist möglich, es ist einfach nicht so einfach, was bedeutet, dass die Fehlersuche in Krisenzeiten viel schwieriger ist.
  2. Das Verfolgen des gesamten Verlaufs eines Features ist viel schwieriger. Befehle zum Durchlaufen des Verlaufs wie git log Geben den Verlauf nur nicht so aussagekräftig mit Bruch aus Repository-Strukturen. Sie können einige nützliche Ausgaben mit Submodulen oder Teilbäume oder andere skriptfähige Methoden erhalten, aber es ist einfach nicht dasselbe wie tig --grep=<caseID> Oder git log --grep=<caseID> Eingeben und alle Commits scannen du kümmerst dich um. Ihre Geschichte wird schwerer zu verstehen, was sie weniger nützlich macht, wenn Sie sie wirklich brauchen.
  3. Neue Entwickler verbringen mehr Zeit damit, die Struktur der Versionskontrolle zu lernen, bevor sie mit dem Codieren beginnen können. Jeder neue Job erfordert das Aufnehmen von Prozeduren, aber das Aufbrechen eines Projekt-Repositorys bedeutet, dass sie dies tun Die Struktur VC) zusätzlich zur Architektur des Codes zu übernehmen. Nach meiner Erfahrung ist dies besonders schwierig für Entwickler, die aus traditionelleren, zentralisierten Shops stammen, die ein einziges Repository verwenden.

Am Ende ist es eine Opportunitätskostenberechnung. Bei einem ehemaligen Arbeitgeber hatten wir unsere Hauptanwendung in 35 verschiedene Sub-Repositories unterteilt. Darüber hinaus haben wir einen komplizierten Satz von Skripten verwendet, um den Verlauf zu durchsuchen, sicherzustellen, dass der Status (d. H. Produktions- und Entwicklungszweige) für alle gleich ist, und sie einzeln oder in großen Mengen bereitzustellen.

Es war einfach zu viel; Zumindest zu viel für uns. Der Verwaltungsaufwand machte unsere Funktionen weniger flink, machte die Bereitstellung viel schwieriger, das Unterrichten neuer Entwickler nahm zu viel Zeit in Anspruch, und am Ende konnten wir uns kaum daran erinnern, warum wir das Repository überhaupt beschädigt hatten. An einem schönen Frühlingstag gab ich 10 US-Dollar für einen Nachmittag Cluster-Rechenzeit in EC2 aus. Ich habe die Repos mit ein paar Dutzend git filter-branch Anrufen wieder zusammengefügt. Wir haben nie zurückgeschaut.

209
Christopher

Christopher hat die Nachteile eines Modells mit einem Projekt pro Repository sehr gut aufgezählt. Ich möchte einige der Gründe diskutieren, aus denen Sie einen Ansatz mit mehreren Repositorys in Betracht ziehen könnten. In vielen Umgebungen, in denen ich gearbeitet habe, war ein Multi-Repository-Ansatz eine vernünftige Lösung, aber die Entscheidung, wie viele Repositorys vorhanden sein sollen und wo die Schnitte vorgenommen werden sollen, war nicht immer einfach.

In meiner aktuellen Position habe ich ein riesiges CVS-Repository mit einem Repository und mehr als zehnjähriger Geschichte in eine Reihe von Git-Repositorys migriert. Seit dieser ersten Entscheidung ist die Anzahl der Repositories (durch die Aktionen anderer Teams) so weit gestiegen, dass ich vermute, dass wir mehr haben, als optimal wäre. Einige Neueinstellungen haben vorgeschlagen, die Repositories zusammenzuführen, aber ich habe mich dagegen ausgesprochen. Das Wayland-Projekt hat eine ähnliche Erfahrung. In einem Vortrag, den ich kürzlich gesehen habe, hatten sie zu einem bestimmten Zeitpunkt über 200 Git-Repositories, für die sich der Lead entschuldigte. Wenn ich mir ihre Website ansehe, sehe ich, dass sie jetzt bei 5 sind, was vernünftig erscheint. Es ist wichtig zu beachten, dass das Verbinden und Aufteilen von Repositorys eine überschaubare Aufgabe ist und es in Ordnung ist, (im Rahmen der Vernunft) zu experimentieren.

Wann möchten Sie möglicherweise mehrere Repositorys?

  1. Ein einzelnes Repository wäre zu groß, um effizient zu sein.
  2. Ihre Repositorys sind lose gekoppelt oder entkoppelt.
  3. Ein Entwickler benötigt normalerweise nur ein oder eine kleine Teilmenge Ihrer Repositorys, um sie zu entwickeln.
  4. Normalerweise möchten Sie die Repositorys unabhängig voneinander entwickeln und müssen sie nur gelegentlich synchronisieren.
  5. Sie möchten mehr Modularität fördern.
  6. Verschiedene Teams arbeiten an verschiedenen Repositorys.

Die Punkte 2 und 3 sind nur dann von Bedeutung, wenn Punkt 1 gilt. Durch die Aufteilung unserer Repositorys habe ich die Verzögerungen unserer externen Kollegen erheblich verringert, den Festplattenverbrauch gesenkt und den Netzwerkverkehr verbessert.

4 und 5 sind subtiler. Wenn Sie die Repos eines Clients und eines Servers aufteilen, ist es teurer, Änderungen zwischen dem Client- und dem Servercode zu koordinieren. Dies kann insofern positiv sein, als eine entkoppelte Schnittstelle zwischen beiden gefördert wird.

Selbst mit den Nachteilen von Multi-Repository-Projekten wird auf diese Weise eine Menge respektabler Arbeit geleistet - Wayland und Boost kommen in den Sinn. Ich glaube noch nicht, dass sich ein Konsens über bewährte Verfahren entwickelt hat, und es ist ein gewisses Urteilsvermögen erforderlich. Tools für die Arbeit mit mehreren Repositorys (Git-Subbaum, Git-Submodul und andere) werden noch entwickelt und experimentiert. Mein Rat ist zu experimentieren und pragmatisch zu sein.

70
Spacemoose

Da wir GitHub verwenden, haben wir tatsächlich mehrere Projekte in einem Repo, aber stellen Sie sicher, dass diese Projekte/Module ordnungsgemäß modularisiert sind (wir verwenden die Konventionen -api und -core + Maven + statische und Laufzeitprüfung und können sogar gehen zu OSGi eines Tages zu booten).

Was spart es? Nun, wir müssen nicht mehrere Pull-Anfragen stellen, wenn wir in mehreren Projekten etwas Kleines ändern. Probleme und Wiki werden zentral gehalten usw.

Wir behandeln jedes Modul/Projekt weiterhin als ein eigenständiges Projekt und erstellen und integrieren sie separat in unseren CI-Server usw.

51
Martijn Verburg

Der Hauptunterschied bei der Verwendung eines oder mehrerer Repositorys besteht für mich in der Beantwortung der folgenden Fragen:

  • Sind die mehreren Teile von demselben Team entwickelt, haben denselben Release-Zyklus, denselben Kunden? Dann gibt es weniger Gründe, das eine Repository aufzuteilen.
  • Sind die mehreren Teile stark voneinander abhängig? Die Aufteilung von Modell, Controller und Benutzeroberfläche (auch wenn es sich um unterschiedliche Teile handelt) ist daher aufgrund der hohen Abhängigkeit voneinander nicht sehr sinnvoll. Wenn jedoch 2 Teile nur eine geringe Abhängigkeit haben, die durch eine stabile Schnittstelle implementiert wird, die nur alle paar Jahre geändert wird, ist es ratsam, die 2 Teile in 2 Repositorys aufzuteilen.

Nur als Beispiel habe ich eine kleine Anwendung (nur Client), die die "Qualität" eines Subversion-Repositorys überprüft. Es gibt die Kernimplementierung, die über die Befehlszeile gestartet werden kann und gut mit Java 6 funktioniert. Ich habe jedoch begonnen, eine Benutzeroberfläche zu implementieren, die JavaFX als Teil von Java verwendet. 8. Also habe ich die 2 aufgeteilt und ein zweites Repository (mit einem zweiten Erstellungsprozess) mit einem anderen Zeitplan erstellt, ...

Ich mag die obigen Antworten (habe sie abgestimmt), aber ich denke, sie sind nicht die ganze wahre Geschichte. Daher wollte ich auch die Argumente für die Aufteilung von Repositorys hinzufügen. Die eigentliche Antwort (wann geteilt werden muss) könnte also irgendwo in der Mitte liegen ...

24
mliebelt

Es könnte sein, dass git-subtree (siehe Atlassian Blog , mittleres Blog oder Kernel Link ) a wäre gut dafür passen Sie. Daher würde jedes Ihrer Top-Level-Projekte einen Teilbaum in möglicherweise unterschiedlichen Versionen verwenden.

In Ihrem Beispiel sollten die Repositorys so eingerichtet sein, wie sie voneinander abhängig sind. Alle Überlegungen zum Entwerfen von MicroServices und Domain Driven Design gelten hier: In einigen Fällen ist doppelter Code akzeptabel, arbeiten Sie mit Schnittstellen, brechen Sie die Kompatibilität nur, wenn Sie dies wirklich müssen usw.

Aus meiner Sicht sollte eine Benutzeroberfläche nun unabhängig vom Backend sein. Daher sollte ein UI-Projekt-Repository normalerweise den UI-Code und den Client-Controller enthalten. Der Client Controller stellt eine abstrakte Verbindung zu Service Controllern her. Sie verwenden eine Service-Client/API-Abstraktion, die separat vom Service versioniert wird, sodass ein Service aktualisiert werden kann, ohne die Clients zu beschädigen (es können mehrere verschiedene Clients vorhanden sein).

Ein Dienst selbst sollte also ein eigenes Repository sein. Meiner Ansicht nach ist der Service nur ein Wrapper einer Single-Point-of-Thuth-Geschäftslogik. Daher sollte die Geschäftslogik normalerweise von der Servicetechnologie getrennt sein, auf der sie gehostet wird. Andererseits ist die Repository-Implementierung normalerweise so eng mit der Geschäftslogik verbunden, dass diese in dasselbe Repository integriert werden kann. Aber auch dort kann Ihr Kilometerstand variieren.

Natürlich können einfache Projekte, bei denen sich die Technologie wahrscheinlich nicht wesentlich ändert oder die mehrere Stacks unterstützen, bei denen alle Benutzeroberflächen von derselben Quelle wie das Backend gehostet werden können und die Backend-Services normalerweise nur von demselben Client verwendet werden, von mehr profitieren eng integrierte Repositories.

In diesem Fall wäre es wahrscheinlich in Ordnung, nur die vollständige Vertikale in einem Repository zu haben und sich darauf zu konzentrieren, sicherzustellen, dass Ihre funktionalen Domänen in ihrem eigenen Repository ordnungsgemäß eigenständig sind. Sie haben dann immer noch die meisten Vorteile kleinerer Repositorys und ansonsten wenig Overhead.

1
Arwin