none
Gemeinsam genutzte Klassen in mehreren GIT-Repositories nutzen RRS feed

  • Frage

  • Hallo Leute,

    ich habe noch wenig Erfahrung mit GIT und suche daher Euren Rat.

    Folgende Ausgangslage:

    Eine Software soll für mehrere Branchen (und Kunden) customized werden. Für jede Variante wird dabei ein eigenes Repository angelegt. Wie verwalte ich dabei am intelligentesten gemeinsam genutzte Klassen, die über alle Varianten hinweg gleich sind?

    Bisher sind diese einfach in allen Varianten im Projekt eingebunden. Änderungen erfolgen an einem "Core"-Repository und werden per Merge in die anderen Repositories übertragen. Geht das noch eleganter? Oder ist das die übliche Vorgehensweise?

    Danke für jeden Tip :)

    Gruß Markus

    Sonntag, 30. November 2014 13:03

Antworten

  • Hallo Markus,

    prinzipiell ist deine Vorgehensweise nicht die verkehrteste. Aus meiner Sicht kommt es stark auf Deine Anwendung drauf an, welcher Weg der eleganteste ist. Je nach Umfang der Basis, die in allen Projekten gleich ist und der der angepassten Module.

    Wenn der größte Teil in der Bais steckt, also in allen Varianten gleich ist, würde ich so vorgehen wie du es schon beschrieben hast. Ein Core-Repo, in dem du nach und nach neue Versionen entwickelst und dann pro Kunde die speziell angepasste Version mit Merge auf die neue Core-Version ziehst.

    Alternative zum Mergen könnten dabei Git Submodule und Git Subtree Merge sein. Kommt halt drauf an, ob deine Verzeichnisstruktur den Einstaz der beiden Methoden hergibt.

    Wenn der größte Teil deiner Anwendung jedoch in den Anpassungen pro Kunde steckt, dann könnte sich auch ein Blick auf NuGet lohnen. D.h. die gemeinsam verwendete Funktionalität verpackst du in DLLs, die du mittels NuGet auf deine angepassten Produktvarianten verteilst. Ich habe dazu mal einen Blogpost verfasst.

    Viele Grüße und gutes Gelingen


    Andreas Richter
    Softwareentwickler und -architekt
    http://www.anrichter.net

    • Als Antwort markiert Markus335 Sonntag, 30. November 2014 23:31
    Sonntag, 30. November 2014 19:06

Alle Antworten

  • Hallo Markus,

    prinzipiell ist deine Vorgehensweise nicht die verkehrteste. Aus meiner Sicht kommt es stark auf Deine Anwendung drauf an, welcher Weg der eleganteste ist. Je nach Umfang der Basis, die in allen Projekten gleich ist und der der angepassten Module.

    Wenn der größte Teil in der Bais steckt, also in allen Varianten gleich ist, würde ich so vorgehen wie du es schon beschrieben hast. Ein Core-Repo, in dem du nach und nach neue Versionen entwickelst und dann pro Kunde die speziell angepasste Version mit Merge auf die neue Core-Version ziehst.

    Alternative zum Mergen könnten dabei Git Submodule und Git Subtree Merge sein. Kommt halt drauf an, ob deine Verzeichnisstruktur den Einstaz der beiden Methoden hergibt.

    Wenn der größte Teil deiner Anwendung jedoch in den Anpassungen pro Kunde steckt, dann könnte sich auch ein Blick auf NuGet lohnen. D.h. die gemeinsam verwendete Funktionalität verpackst du in DLLs, die du mittels NuGet auf deine angepassten Produktvarianten verteilst. Ich habe dazu mal einen Blogpost verfasst.

    Viele Grüße und gutes Gelingen


    Andreas Richter
    Softwareentwickler und -architekt
    http://www.anrichter.net

    • Als Antwort markiert Markus335 Sonntag, 30. November 2014 23:31
    Sonntag, 30. November 2014 19:06
  • Hallo Andreas,

    vielen Dank für Deine Antwort. Das was in allen Varianten gleich ist sind ungefähr 5 - 10 % vom gesamten Code. Die Software wird insgesamt immer sehr stark für ganz verschiedene Branchen angepasst. Das betrifft leider immer alle Bereiche (Anzeige + Programmablauf + Business-Logik).

    Ich werde mir die Git-Submodule-Funktion mal anschauen.

    Viele Grüße

    Markus


    • Bearbeitet Markus335 Sonntag, 30. November 2014 21:32 RS
    Sonntag, 30. November 2014 21:32