Hallo Aviator,
zunächst ist es gut, dass du einzelne repositories für die verschiedenen Projekte hast.
Wir haben bei uns oft sehr ähnliche Strukturen und lösen das ganze wie folgt:
- Common wird als Submodule in den jeweiligen Projekten eingebunden
- die DLLs werden als Submodule der Hauptanwendung eingebunden
So hattest du es ja auch schon angedeutet. Das ganze hat dann folgende Struktur:
Code:
L MainApp
L Common
L
DLL 1
L Common
L
DLL 2
L Common
L
DLL 3
L Common
Natürlich hast du dann das "Problem", dass du in jeder
DLL das Submodule "Common" aktualisieren musst, wenn es Änderungen gibt. Das ist ja aber eigentlich auch richtig so. Denn diese Änderungen müssen im jeweiligen Projekt ja erstmal getestet werden. Das ganze lässt sich bei Bedarf ja aber auch automatisieren. Mit dieser Struktur hast du in jedem Fall die beste Rückverfolgbarkeit.
Eventuell muss noch ein git submodule update
gemacht werden wenn ich das richtig verstanden habe.
Das hast du richtig verstanden. Es gibt verschiedene git Clients (Sourcetree oder ähnliches), welche automatisch die Submodules updaten.
Wenn ich jetzt in einer der Common Files etwas ändere und einen Commit ausführe, dann weiß prinzipiell ja nur das Hauptprojekt etwas davon. Die DLLs sind immer noch nicht abhängig vom Common Verzeichnis, richtig? Und auch im Hauptprojekt werden die Änderungen nur protokolliert, wenn ich davon auch einen Commit absetze, oder?
Verwendest du meine obrige Struktur, dann kannst du in jedem Projekt (MainApp, DLL1, DLL2, ...) das Common-Verzeichnis verändern. Danach einfach die Änderungen committen und pushen. Danach kannst du diese Änderungen logischerweise mit einem pull in den anderen Projekten einpflegen, testen und auch dort committen.
Grüße
Headbucket