![]() |
AW: [GIT] Organisation von Library-Varianten, Best practices
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. |
AW: [GIT] Organisation von Library-Varianten, Best practices
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. |
AW: [GIT] Organisation von Library-Varianten, Best practices
Ihr habt ja beide Recht, so in der Art halte ich das ja auch bei mir.
Ich hätte nur gedacht das es einen cleveren Workflow bei GIT dafür gibt. Zitat:
Ich versuche schon den größten Teil gleich zu halten, und immer mehr Teile mitzuziehen, aber bei manchen alten Projekten lohnt sich der Aufwand eben nicht immer. Z.B. habe ich früher TMS WebUpdate benutzt um Software-Updates runterzuladen, das mache ich mittlerweile mit einer eigenen Lösung. Was mache ich jetzt mit den alten und neuen Projekten ? Theoretisch müsste ich doch dann alle diese Teil-Funktionalität in eigene (sub)module verfrachten, also update-tms, update-neu, um diese Funktionalitäten sauber zu kapseln (denn sie sind nicht kompatibel). Noch habe ich verschiedene Library-Stände für diverse Projektstände eingefroren, und das funktioniert ganz gut. Mache ich zwar noch nicht ganz sauber mit Tags, aber das ist geplant. Vielleicht bleibe ich besser dabei bis sich die alten Zöpfe mal von selbst erledigt haben. Vielen Dank erstmal für die Denkhilfen. Rollo |
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:48 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz