Also ich habe mal die folgenden Punkte versucht zu klären,
bin aber immer noch nicht ganz klar was jetzt der Beste Weg ist.
- Besser Subtree statt SubModule um verschiedene Libraries zu Projekten hinzuzufügen
Vorteile: Mit SubTree squash kann der Subtree ohne History eingebaut werden.
Ansonsten verhält sich ein Subtree mehr oder weniger wie ein Unterverzeichnis im Projekt.
Bei Submodules sind bei commit immer mehrere Dinge und Abläufe zu beachten, das sollte bei Subtree dann viel einfacher und intuitiver sein.
Allerdings denke ich dass auch mit Subtree eine Zuordnung unt Projekt komplett vergurkt werden kann wenn mal mal etwas vergisst und die falsche Taste drückt.
- Eine große Library statt einer Library mit Submodulen/Subtrees
Das macht wohl Google auch so, mit Terabytes an Code.
- Das Aufsplitten in weitere Unter-Libraries macht nur mehr Verwaltungsaufwand im GIT Workflow
- Nachteil solcher großen, universellen Libraries ist natürlich das man Teilfunktionen nicht schnell und einfach separat herausziehen kann,
falls man das mal braucht.
- Die Teilaufgaben in solchen großen, universellen Library sind normalerweise schon gut in Units separiert, das sollte zur Separation ausreichen.
- Nachteil: Allerdings könnte man auch immer mal etwas an den Kernfunktionen umbauen, welche sich dann gleich in zig Teilfunktionen auswirken können, die man erst fixen muss bis es wieder komplett läuft.
Das sollte aber am Ende auch immer ein Vorteil sein, weil es den Entwickler zwingt immer alle Teilfunktionen gleich auf dem aktuellen Stand zu halten,
so dass es im Ganzen kompilierbar bleibt.
Jedenfalls wird das Separieren von Arbeiten an Teilaufgaben dabei wohl etwas erschwert.
Soweit wäre meine Einstellung bis jetzt dazu, d.h. die eine große Library, die ich jetzt habe, wäre schon OK vom Verwaltungsaufwant und Merging.
Ganz im Klaren bin ich mir über den optimalen Aufbau aber noch nicht,
ich habe jetzt dazu kaum konzeptuelle, strategische Dokumentationen im Web gefunden.
Bei Verwendung von Submodulen, aber auch Subtrees, muss man wohl auch sehr auf GIT-Fehleingaben achten um nicht alles zu schrotten.
Genau deshalb habe ich das so noch nicht wirklich produktiv eingesetzt, bis ich wirklich genau weiss wie das am Besten und Sichersten gemacht werden kann.
Meine ursprüngliche Idee war eigentlich die Teilfunktionen einer Library in separate GIT Repositories aufzusplitten, und diese dann wieder in ein komplettes Library Repositry zusammenzufassen.
Welches dann als eine zentrales Library-Repositry zu jedem Projekt hinzugefügt werden könnte, wobei die einzelnen Teil-Funktionen durchaus andere Stände haben könnten.
Das ist aber schon bei den ersten Überlegungen eine gruselige Vorstellung.
Das mit den Teil-Libraries ginge aber auch in die Richtung von z.B. NPM, Composer und anderen Packagemanagern, die quasi Projekte "komponieren" können.
Das würde dann schon Sinn machen, aber womöglich nur bei externen Libraries.
Die einzele, große Library hingegen, lässt sich eigentlich gut verwalten.
Es spricht wenig bis nichts dagegen.
Vielleicht hat noch jemand einen ganz anderen Aufbau im Einsatz, wäre interessant mal die Vor- und Naxchteile zu sehen.