Was ich da gezeigt habe ist ja nicht immer zwingend, es soll nur das Problem verdeutlichen.
Es gelingt auch ab und an Alles wieder zu einem Master zu mergen.
Nur entstehen die Feature-Branches eben dadurch das auch nebenbei mal Projekte fertiggemacht werde müssen.
Die Ganzen Features entstehen dann meist, so wie jetzt auch, bei großen Wechseln von Rx10.3 auf Rx10.4,
oder auch bei
SDK-Wechsel der
OS,
wo eben viele Dinge siche ändern können, und separat gefixt werden müssen.
Nach einiger Zeit ist es dann auch stabil, und wenn Zeit ist wird es auch gemergt so gut es geht.
Weil die einzelnen Units so klein wie möglich sind ist es auch machbar, aber die
API's driften doch oft von
einem Standard zu einem ganz anderen Hin.
Nimm als Beispiel nur mal TWebBrowser, sowas verdient schon seinen eigenen Feature-Branch.
Wobei z.B. in Win kann es bleiben, in iOS muss es so ind Android anders gemacht werden.
Mit IFDEF Kapseln geht ja meist, aber es kann auch sein das diese Features erstmal völlig inkompatibel werden.
Es geht mir eigentlich um einen optimalen Aufbau, der das sehr gut Abfangen kann.
Ist das mit den Features dann der richtige Weg, oder gibt es Alternativen ?
Z.B. könnte statt einer großen Library (die ich jetzt habe), das in mehrere einzele Teilfunktion mit separatem GIT aufgeteilt werden.
Das erhöht aber auch den Verwaltungsaufwand.