Großes Projektlayout: Hinzufügen einer neuen Funktion für mehrere Unterprojekte

Ich möchte wissen, wie man ein großes Projekt mit vielen Komponenten mit dem Versionsverwaltungssystem verwaltet.

In meinem aktuellen Projekt gibt es 4 Hauptteile.

1. Netz
2. Server
3. Admin-Konsole
4. Plattform.

Der Web- und Serverteil verwendet 2 Bibliotheken, die ich geschrieben habe. Insgesamt gibt es 5 Git-Repositories und 1 Quecksilber-Repository. Das Projekterstellungsskript befindet sich im Plattform-Repository. Es automatisiert den gesamten Bauprozess.

Das Problem ist, wenn ich eine neue Funktion hinzufüge, die sich auf mehrere Komponenten auswirkt. Ich muss für jedes betroffene Repo einen Zweig erstellen. Implementieren Sie die Funktion. Merge es zurück. Mein Bauchgefühl ist "etwas stimmt nicht".

Soll ich also ein einzelnes Repo erstellen und alle Komponenten dort platzieren? Ich denke, die Verzweigung wird in diesem Fall einfacher. Oder ich mache einfach das, was ich gerade mache. In diesem Fall, wie löse ich das Problem der Erstellung eines Zweigs in jedem Repository?

In der von Ihnen beschriebenen Situation profitieren Sie nicht von mehreren Repositorys, aber Sie haben Kosten: Sie können nicht auf eine ältere Version eines Repositorys zurücksetzen und können sicher sein, dass Ihr System weiterhin funktioniert. Dies liegt daran, dass Ihr Code über Repositorys hinweg eng gekoppelt ist. Da das Vertrauen in die Fähigkeit zum Rollback einer der Hauptvorteile der Quellcodeverwaltung ist, ist dies nicht die Situation, in der Sie sich befinden möchten.

Die Lösung besteht darin, Ihre Repository-Struktur basierend auf der Kopplung des darin enthaltenen Codes zu definieren: Wenn die Projektkomponente A nur stabile Schnittstellen mit der Projektkomponente B gemeinsam hat, können sie in separaten Repositorys abgelegt werden. Andernfalls sollten sie sich im selben Repository befinden. Ein detaillierteres Repository-Layout spiegelt eine besser berücksichtigte Systemarchitektur wider.

Wenn es sich bei jedem Ihrer Repositorys um eigenständige Projekte oder Bibliotheken handelt, ist es meiner Meinung nach nicht grundsätzlich falsch, Feature-Zweige für jedes Repository zu erstellen, wenn neue Features hinzugefügt werden, die projektübergreifend sind. Als eigenständiger Server kann jeder unabhängig versioniert werden, und Sie können alte APIs ablehnen.

In Ihrem speziellen Fall klingt es jedoch so, als würden Ihre Repositorys Ihren Code möglicherweise nicht effektiv gruppieren. Wenn Änderungen an Code in einem Repository Änderungen an anderen erfordern (außer Verfall), ist entweder Ihre Kopplung zu eng, oder die Repositorys sollten neu organisiert werden.

Wenn alle Repositorys wirklich Teil desselben Projekts sind (sie können nicht alleine stehen), sollten Sie vielleicht nur ein Repository haben. (Oder vielleicht 2: das Hauptprojekt und eines für generische / standardisierte Funktionalität.)