Hallo zusammen,

ich würde gerne GIT Workflows optimieren, und möglichst wenig mergen,
falls das überhaupt möglich ist.

Das Problem ist das ich eigentlich eine Quelle habe (und haben möchte), für die Kern-Sourcen.
Diese gibt es aber immer mal in leichten Versionen und Varianten,
weil ich genötigt bin z.B. für Android/iOS und/oder Rx10.3.x und 10.4 verschiedene Wege zu gehen, damit es läuft und kompilierbar ist.

Also es sieht so in der Art aus, das es eigentlich keinen stabilen Master gibt,
sondern eigentlich eher mehrere Master, je nach Konfiguration.

markieren

Delphi-Quellcode:

Master -------------------------------------------- # z.B. das ist produktiv für Win OK
Feature Rx10.3 \-----------------------------------
                 \iOS -----------------------------
                 \Android ------------------------- # z.B. das ist produktiv für Android OK
Feature Rx10.4 \-----------------------------------
                 \iOS ----------------------------- # z.B. das ist produktiv für iOS OK
                 \Android -------------------------

Ich bin also oft gezwungen ein Projekt in verschiedenen Features zu pflegen, die dann für mich als Master fungieren.

Leider kann ich das nicht mergen, es sei denn ich würde da mit allen Möglichen IFDEF's und sonstigen Tricks arbeiten.
Eine saubere Trennung ist nur schwer möglich, weil es meistens auch XML, DPROJ, und andere Dateien betrifft.
Das Ganze wird auch noch durch verschiedene OS-Versionen beeinflusst, die dann ganze API's abkündigen oder umstellen.


Ich möchte aber Vermeiden das die Feautures immer weiter auseinanderdriften, und hoffe das die irgendwann doch mal alle in einen Master gemerged werden können.

Meine Frage:
Gibt es für solche Fälle einen perfekten, optimalen Workflow in GIT, sollte ich das evtl. komplett anders strukturieren
(z.B. ein Projekt pro Platform, pro IDE-Version, ...) ?

Wie macht Ihr das ?

Ich entwickle auch für mehrere Plattformen, ohne Android. Ich finde, Plattformbesonderheiten kann man recht gut verstecken. Ein Stapel IFDEFs ist nicht vermeidbar, dazu getrennte Methoden, die abhängig von der Umgebung verwendet werden sollen. Alles normal. Wenn nun eine Änderung erfolgt, die nicht spezifisch für eine Plattform ist, muss die in alle Zweige eingebaut werden, also muss doch gemerged werden. Du könntest jetzt von Deinem Master immer wieder in die jeweiligen Besonderheiten mergen, oder eben doch einen Master mit allen Plattformen haben, von dem lediglich aktuelle Entwicklungs- und Testzweige abgehen. Der Vorteil Deines Ansatzes ist die klare Trennung der Plattformen im Repository, erkauft mit unter Umständen abweichenden Implementierungs- und Featureständen und Redundanzen. Meine Variante erledigt die Trennung im Code, was ihn ab einer bestimmten Detailebene unübersichtlich macht.

Und ich entwickle nur für eine IDE Version... Fehler, die in Kompilaten auftreten, die mit einer alten Version gemacht wurden, werden durch ein Update bereinigt.

Sherlock

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.

Vielleicht muss ich noch dazu sagen, dass ich die Projekte sehr schlank aufbaue, und mehr oder weniger nur konfiguriere.
Wärend die eingentliche Programm-Logik und Views dann in der zentralen Library liegen.

Project-1 ------------------------------ Library, mit konfigurierbaren, universellen Views und Logik
Project-2 --------------/
Project-3 -------/
Project-4 --/
...

So dass Erweiterungen dann meist in der zenttraleen Library passieren, und nicht im Projektcode.

Das hat Vor- und Nachteile:
+ Eine Fehlerbehebung behebt das gleich in allen Projekten
- Eine Erweiterung in Projekt 1 hat dann mögliche Auswirklungen auf andere Projekte

Insgesamt reduziert das meine Redundanzen enorm, wenn da nicht diese ständigen, ungeplanten Plattform-Änderungen wären.

Hast Du das als Submodule eingebunden? Oder ist das ein eigenständiges Repository?

Sherlock

Nein, ich habe nur die gesamte Library im GIT,
und jedes Projekt nochmal einzeln.

Die SubModule würde noch einen Level an Komplexität dazubringen,
ich denke der hilft mir im Moment nicht viel.
Wenn ich an einem Projekt arbeite lade ich das entsprechende Feature.
Natürlich ist der Plan das mal mit SubModule zu machen, aber dann sollte der Workflow klar sein.

Bin mir da noch nicht ganz im Klaren ob und wie man das umstellen könnte.

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.