Einzelnen Beitrag anzeigen

Rollo62

Registriert seit: 15. Mär 2007
3.932 Beiträge
 
Delphi 12 Athens
 
#7

AW: [GIT] Organisation von Library-Varianten, Best practices

  Alt 14. Mai 2018, 11:03
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
  Mit Zitat antworten Zitat