Kann GIT sowas oder sonstigen Tool?

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

Aufgrund der Corona-Krise: Die Veröffentlichung von Stellenangeboten und -gesuchen ist bis 31.12.2020 kostenfrei. Das beinhaltet auch Angebote und Gesuche von und für Freischaffende und Selbstständige.

  • Kann GIT sowas oder sonstigen Tool?

    Hi,

    ich stehe vor einer neuen Herausforderung. Um das Problem zu erklären muss ich leider etwas weiter ausholen:

    ich habe eine sehr umfangreiche Applikation geschrieben, die bereits einige Jahre in Deutschland und ein paar anderen Ländern eingesetzt wird. Nun soll diese App auch global ausgerollt werden. Allerdings nur ein kleiner Teil davon also in seiner Funktionalität stark eingeschränkt.

    es wäre nun kein Problem die nicht benötigten Funktionen einfach mit einem if verschwinden zu lassen aber.... Die globale Version benötigt eine deutlich aufwendigere Validierung als wir bisher hatten.
    Das bedeutet jede Funktion und Methode muss in einem extra SDS dokumentiert und erklärt werde. Also was macht die Funktion, warum macht sie das und was in Gottes Namen hat sich der Author dabei gedacht die zu schreiben :)

    wenn ich das für die ganze Software machen soll, dann verdiene ich zwar gut Geld aber mein Auftraggeber hätte da bestimmt kein Verständnis für. Also wäre mein Ziel, aus der Applikation für global allen Code herauszulöschen der nicht gebraucht wird um den validierungs-Aufwand so klein wie möglich zu halten.

    Nun möchte ich aber bei zukünftigen Änderungen, bugfixes und Erweiterungen nicht immer zwei Sourcen pflegen. Wenn ich nun aber sagen wir mal in GiT einen neuen Branch anlege und dort alles lösche das nicht gebraucht wird und dann im Branch der die „große“ Version benutzt weiter arbeite, dann würde beim nächsten merge des bearbeiteten Branchen doch wieder die gesammte Funktionalität in den „kleinen“ Branch hinzugefügt oder?

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Hallo Claus,

    wir hatten so etwas auch schon einmal. Gelöst wurde es seinerzeit mit Anweisungen für den Compiler. Gesteuert wird das ganze über eine zentral gesetzte Variable. Der komplette Sourcecode bleibt somit weiterhin für beide kompilierten Versionen erhalten.

    Entspricht von der Vorgehensweise Deinem Ansatz mit der IF-Abfrage vor jeder Funktion. Ist nur wesentlich eleganter weil der die kompilierte Version die nicht benötigen Funktionen nicht enthält.

    Solltest Du den Sourcecode zur Evaluierung vorlegen müssen, kannst Du Dir ein Marco schreiben, dass Dir die benötigten Teile heraus kopiert. ;)
  • OSXDev schrieb:

    Hallo Claus,

    wir hatten so etwas auch schon einmal. Gelöst wurde es seinerzeit mit Anweisungen für den Compiler. Gesteuert wird das ganze über eine zentral gesetzte Variable. Der komplette Sourcecode bleibt somit weiterhin für beide kompilierten Versionen erhalten.

    Entspricht von der Vorgehensweise Deinem Ansatz mit der IF-Abfrage vor jeder Funktion. Ist nur wesentlich eleganter weil der die kompilierte Version die nicht benötigen Funktionen nicht enthält.

    Solltest Du den Sourcecode zur Evaluierung vorlegen müssen, kannst Du Dir ein Marco schreiben, dass Dir die benötigten Teile heraus kopiert. ;)

    Das mit dem Compiler ist schwierig bei einer JS App :) Aber ich denke da wird es irgendwie drauf hinauslaufen, dass ich mir ein script schreiben muss das die nichgt benötigten Teile auslöscht. Dachte nur sowas kommt öfter mal vor und es gäb da was fertiges. Vielleicht sogar ein Jenkins Plugin oder sowas.

    Danke

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • vielleicht geht das mit gitignore. Also das Große wird in das Kleine gemergt, aber beim Commit wird ein Teil ignoriert.

    Alternative in drei Teile aufteilen: große Anwendung, kleine Anwendung und gemeinsame Lib. In der Lib kann natürlich viel mehr drinnen sein, als die kleine Anwendung braucht.

    Es gibt auch noch git-sub-irgendwas. Ein Repo besteht aus mehreren Repos. Quasi Sub-Repos.
  • Thallius schrieb:


    .Nun möchte ich aber bei zukünftigen Änderungen, bugfixes und Erweiterungen nicht immer zwei Sourcen pflegen. Wenn ich nun aber sagen wir mal in GiT einen neuen Branch anlege und dort alles lösche das nicht gebraucht wird und dann im Branch der die „große“ Version benutzt weiter arbeite, dann würde beim nächsten merge des bearbeiteten Branchen doch wieder die gesammte Funktionalität in den „kleinen“ Branch hinzugefügt oder?
    in dem von dir genannten „kleinen“ Branch machst du ein Rebase auf den Master
    Dann hast du alles was im Master neu ist auch in deinem „kleinen“ branch
    Die Änderungen werden durch den Renate oben drauf gepackt
    Du musst dann natürlich neue Änderungen die Nicht im „kleinen“ branch wieder entfernen



    Ich weiß nicht wie deine Struktur aussieht
    Klingt aber so als wenn du deine Anwendung so Strukturen müsstest dass du 2 Anwendungen hast und dir die Inhalte als „dependency“ rein holst

    dann hast du einmal den kompletten Code
    Und dann 2 Projekte die im Prinzip nur aus sowas wie
    node.packages
    .gradle
    podfile

    Oder was auch immer besteht
    Ich weiß nicht immer wovon ich rede aber ich weiß das ich Recht habe. :saint: