[GIT] Organisation von Library-Varianten, Best practices

[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 ?

[TigerLilly]

Für mich ist es so:
Zwei oder mehr gleichzeitig lebende Branches sind ein Problem, denn dann hast du zwei Codestücke, die du warten musst. Ein Branch wird entweder gemerged, dauerhaft beendet oder in ein eigenes Projekt ausgegliedert. Bei uns gilt:
- ein Branch muss einen genau umrissenen Zweck haben
- es muss klar sein, wann der Branch wieder gemerged wird

Wahrscheinlich ist das aber auch Geschmackssache oder eine Frage des Entwicklungsprozesses bzw wenn es funktioniert ist es eh ok.

[Schokohase]

Das eigentliche Problem taucht ja nicht im normalen Lebenszyklus der Bibliothek (Erweiterung, BugFix) auf, sondern immer dann wenn es Breaking Changes gibt.

Da muss man sich einen eigenen Weg suchen.

Mit einem neuen Repository würde ich z.B. dann starten, wenn die Bibliothek komplett neu geschrieben wird.

Ein Release-Stand wird mit einem Tag versehen und genau daran knüpft man auch die Submodule. Dann baut man die Anwendung A mit dem Submodule B (Tag 1.2.3) und exakt das gleiche kann ich auch ein paar Monate später genau so wieder erzeugen. Änderungen am Submodule bekommt man, indem man bewusst und explizit die Version (den Tag) dort umstellt und prüft, ob das auch wirklich noch mit der Anwendung zusammenpasst.