[GIT] Organisation von Library-Varianten, Best practices

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