[GIT] Organisation von Library-Varianten, Best practices

[Rollo62]

Hallo zusammen,

ich hoffe der Titel passt einigermassen.

Meine Frage ist ob man in GIT sinvollerweise mehrere PARALLELE Stränge von Pseudo-"mastern" aud Dauer nebeneinander laufen lassen sollte.
Das insbesondere z.B. für NEUE und ÄLTERE Libraries, die inverschiedenen Situationen benutzt werden können und dann jeweils leicht (oder auch stärker) angepasst werden müssten.

Teilweise mache ich das schon so, aber eigentlich nur um kleinere Differenzen abzufangen.

Mit geht es darum aus im Moment MEHREREN, speziellen Libraries die vorhanden sind, diese
in EINE Librarie zusammenzuführen.
Diese könnten dann in den entsprechenden Projekten über z.B. "master-desktop", "master-mobile", "master-console", oder aber auch "master-VCL", "master-FMX", etc. eingebunden werden.

Also z.B. so in der Art
"master" - der Hauptstrang, in dem hoffentlich immer mehr Gemeinsames zusammenläuft
"master-desktop" - enthält die Library mit spezifischen Optimierungen für desktop
"master-console" - enthält die Library mit spezifischen Optimierungen für console
"master-desktop-VCL" - enthält die Library mit spezifischen Optimierungen für desktop VCL
"master-desktop-FMX" - enthält die Library mit spezifischen Optimierungen für desktop FMX
"master-mobile" - enthält die Library mit spezifischen Optimierungen für mobile
"master-delphi5" - enthält die Library mit spezifischen Optimierungen für alte Projekte
...

Würde eine solche Zusammenführung, falls überhaupt möglich gemeinsam zu verwalten, überhaupt Sinn machen ?
Immerhin würden diese Stränge womöglich IMMER weiter auseinanderlaufen, und man könnte vielleicht nur selten mal hier und da ein paar Units vereinheitlichen.

Der Grundgedanke und die Ziele wären aus meiner Sicht:

• das so zumindest immer EINE "Mutter"-Library für ALLES gehalten werden kann.
• das die "master" dauerhaft nebeneinander produktiv im Einsatz wären
• das die Chance bestünde Units zu vereinheitlichen, wenn das sinnvoll erscheint.
• das man verschiedene Frameworks sauber gegeneinander kapseln könnte (VCL, FMX, FMX-Linux, TMS, JEDI, ...),
  in der Hoffnung das diese mal näher zusammenlaufen könnten.
• das eine zentrale Verwaltung ALLER Libraries zur Nutzung in verschiedenen Projekten ermöglicht würde

Ich weiss das man in GIT Submodule nutzen kann, aber das ist nicht ganz auf das ich hinaus möchte.

Würde eine solche Struktur machbar sein, und Sinn machen ?
Wenn ja, wie sollte man solche verschiedenen Aspekte am sinvollsten zusammenführen ?
Vielleicht arbeitet ja schon jemand in der Art, und es gibt ein paar Tips aus der D-Gemeinde.

Rollo

[freimatz]

Nicht sicher bin ich das alles verstanden zu haben.
Mein Gedanke dazu: erst mal nach "Best practices" zu fragen und dann submodule nicht wollen passt nicht zusammen.

[Rollo62]

Ich wollte nicht submodules nicht wollen :stupid:
Ich wollte wissen ob, wie und was man am Besten einsetzen sollte.

Wenn es mit submodules mehr Sinn macht dann bitte, kein Problem.

Generell denke ich aber es geht nicht um mit/ohne submodules,
es geht eher darum ob in einem "module" mehrere verschiedenen "Varianten" gekapselt werden sollten oder nicht.
So das mehrere Feature-Stränge entstehen, die ich dann auf Dauer als "master" für verschiedene Anwendungen nutzen würde.

Ist das guter Stil, oder hält man besser alle Varianten in komplett verschiedenen GIT-Modulen ?

Rollo

[freimatz]

Wenn man von einem Code Varianten hat, die alle weiterentwickelt werden, so würde ich dazu ein git repository nehmen und für jede Variante darin einen branch anlegen.
Die Projekte die dann solch einen Code benutzten würden dann das obige repository als submodul einbinden. Da wird dann auf einen bestimmten commit verwiesen der dann benutzt wird. So kann man einfach die Variante wechseln.

[Rollo62]

Zitat:

By remembering this core concept and reflecting on it, you can understand that submodule support some workflows well and less optimally others. There are at least three scenarios where submodules are a fair choice:

• A. When a component or subproject is changing too fast or upcoming changes will break the API, you can lock the code to a specific commit for your own safety.
• B When you have a component that isn’t updated very often and you want to track it as a vendor dependency. I do this for my vim plugins for example.
• C. When you are delegating a piece of the project to a third party and you want to integrate their work at a specific time or release. Again this works when updates are not too frequent.

Die Rede ist hier von submodules in einem main-modul (Projekt).
Wenn ich aber mehrere Branches in den submodules habe, wird dann die ganze Verwaltung nicht schnell zu undurchsichtig ?

Man könnte z.B. vielleicht auch eine Schicht dazwischenschalten, also

Delphi-Quellcode:

Projekt1 - submodule1 - branch feature1 - 
                                          \  
Projekt2 - submodule2 - branch feature2 --  submodule comon base
                                          /  
Projekt3 - submodule3 - branch feature3 -

Wenn die submodules 1-3 quasi den master branch für das jeweilige Projekt darstellen.
Dann wären zumindest Projekte und Library sauberer getrennt, und Änderungen in submodule1 könnten (womöglich) leichter gewartet werden.

Update:
Ginge das nicht in die Richtung fork mit pull request ?
Würde sich das für ein internes GIT lohnen, oder ist der Aufwand zu hoch ?

Zitat:

This is a very common workflow: you start using someone else’s project as submodule but then after a while you find the need to customize it and tweak it yourself, so you want to fork the project and replace the submodule with your own fork. How is that done?

The submodules are stored in .gitmodules:

$ cat .gitmodules
[submodule "ext/google-maps"]
path = ext/google-maps
url = git://git.naquadah.org/google-maps.git

You can just edit the url with a text editor and then run the following:

$ git submodule sync

This updates .git/config which contains a copy of this submodule list (you could also just edit the relevant [submodule] section of .git/config manually).

Rollo

[TigerLilly]

Ich bin nicht sicher, ob die Versionskontrolle hier das geeignete Mittel ist, um abzubilden, was du möchtest.
Wie sollen sich denn zB Änderungen am MASTER auf MASTER-DESKTOP auswirken?
Mit einem Branch entkoppelst du den gebranchten Code von der anderen Entwicklungslinie. Und ein Branch, der nicht irgendwann wieder gemerged wird, ist grundsätzlich ein Problem.

Wie benutzt du denn deine Libs, wie änderst du sie + wie sollen sich diese Änderungen auswirken?

[Rollo62]

Der Fakt ist das es Library-Stände aus verschiedenen Projekten gibt, die teilweise
für ältere Systeme gebaut wurden, und mittlwerweile weiterentwickelt oder ersetzt wurden.
Ich halte die im Moment separat, aber es gibt einen Großteil der "Common" ist, und den man
zentralisieren könnte.

Die Frage ist halt ob und wie man das in einem GIT module über Branches machen sollte, oder besser nicht ?
Defakto wäre der "alte" LibraryBranch dan u..U. auf ewig eingefroren, wenn es keine Weiterentwicklung gibt.
Wenn man aber doch mal z.B. die neuen Win10 Dialoge anpassen muss, dann könnte der "alte" Branch dafür aktualisiert werden.

Den Vorteil (Hoffnung) der Branches sehe ich darn das man solche Units step-by-step bei Bedarf mal zusammenführen könnte, wenn man diese mal wieder braucht und anfasst.
So in der Art das die perfekten, universellen Units über die Zeit hochbubbeln ...

Auf der anderen Seite werden die Branches in der Praxis wohl eher immer weiter auseinanderlaufen, das ist die Befürchtung.
Ich glaube auch das die Verwaltung am Ende sehr unübersichtlich werden kann, als Alternative steht die komplett separierte, eingefrorene Library, die ich natürlich auch bei Bedarf anpassen kann.
Nur wäre diese jeweils unter den Projekten, und nicht zentral verwaltet.

Meine Frage geht in die Richtung ob es wohl schon einen idealen GIT-Workflow dafür gibt, um solche leicht verschiedene Varianten/Anpassungen zusammenzuführen.
Beispiele hätte ich da etwa

• Alte/neue Projekte vor und nach Unicode ...
  Ich würde gerne erst bei Bedarf die alten Unit/Implementierungen mergen, so das am Ende nur eine Unit/Implementierung übrigbleibt.
• Verschiedene Unit/Implementierungen von SendMail unter Android-Versionen, iOS Versionen
• Altes Projekt mit Zeos, neue Projekte mit Firedac
• Neues Feature, z.B. Notifications, einfach in alte Projekte bringen.

Wenn man das weiter denkt komme ich dann z.B. auf Projekte mit JEDI, TMS und DevExpress, würde man diese dann z.B. auch als submodule einbinden und deren Entwicklungs-Stufen mitführen.
Ich habe zwar mittlerweile die drei rausgeworfen, aber in alten Projekten leben sie noch weiter.
Ich habe schon teilweise davon Minimal-Versionen angelegt, um die paar Features die ich daraus nutze leichter weiterführen zu können, und irgendwann komplett rauszuwerfen.

Rollo

[TigerLilly]

Hmm. Versionskontrolle braucht es natürlich, aber ich würde das, was du vorhast, anders angehen. Dein erster Schritt ist ja die Harmonisierung und Vereinheitlichung des Codes, bzw alle Libs in eine Codebase zu bringen. Ab dann macht die Versionskontrolle dafür erst richtig Sinn.

Ich kenne deinen Code nicht, aber ich würde versuchen, über INCLUDEs und DEFINEs eine gemeinsame Codebasis zu erstellen und dann nach und nach doppelten Code zu identifizieren und in sowas wie COMMON oder BASE auszulagern. MIDAS und PEGANZA helfen da sicher.

[Rollo62]

Genau das ist die Frage.
Ob es Sinn macht zur Vereinheitlichung das Zusammenzulegen.

Ich habe bisher auch eher Alles separat verwaltet bei grösseren Brüchen, und die alten Stände eingefroren.
Dke Idee ist das GIT durchaus beim Reorganisieren helfen könnte.
Bin aber auch zu 80% der Meinung das wird nur bei relativ verwanten Ständen etwas Nutzen.
Könnte ja sein das schonmal jemand so damit gearbeitet hat.
Ich denke da z.B. an den VCL zu FMX Bruch o.ä., wo vielleicht jemand beides in einem Modul verwaltet hat.

[Rollo62]

Mal adersrum.
Wenn du der Meinung bist das branches immer gemerged werden müssen macht mein Plan keinen Sinn.
Das kann ich gut nachvollziehen,aber ist das wirklich so gedacht ?
Es gibt doch oft feature branches die nicht mehr weiterentwickelt werden, sollte man sowas evtl. By-design und nicht nur by-accident machen ?