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.