GIT Projektverwaltung Best Practice

[Aviator]

Hallo Delphianer,

heute mal wieder mit einem Problem statt einer Lösung. :stupid:


Ich habe die folgende Projektstruktur (vereinfacht dargestellt):

Code:

ProjectGroup  
  L MainApp
      L  [..\Common]   <--- Liegt in einem übergeordneten Verzeichnis
          |
          L *.pas / *.dfm
      L  Source
          |
          L *.pas / *.dfm
  L DLL 1
      L  [..\Common]   <--- Liegt in einem übergeordneten Verzeichnis
          |
          L *.pas / *.dfm
      L  Source
          |
          L *.pas / *.dfm
  L DLL 2
      L  [..\Common]   <--- Liegt in einem übergeordneten Verzeichnis
          |
          L *.pas / *.dfm
      L  Source
          |
          L *.pas / *.dfm
  L DLL 3
      L  [..\Common]   <--- Liegt in einem übergeordneten Verzeichnis
          |
          L *.pas / *.dfm
      L  Source
          |
          L *.pas / *.dfm

Die Hauptanwendung, die einzelnen DLLs und das Common Verzeichnis sind derzeit eigenständige GIT Repositories.

Jetzt ist es so, dass die Hauptanwendung nur mit einer bestimmten Version der DLLs funktioniert weil beispielsweise in einer anderen Version ein gemeinsam genutzter Type oder ein Interface angepasst wurde. Wenn ich jetzt aber einen bestimmten Stand der Hauptanwendung aus dem GIT Repository auschecken möchte, brauche ich ja auch auch die passenden DLL Projekte.

Da hat GIT ja etwas schönes im Angebot was sich Submodules nennt. Da wird dann immer der Stand der Submodules aus dem Repository ausgecheckt, auf den beim Commit verwiesen wurde. Also checke ich den Stand der Hauptanwendung aus und erhalte (automatisch?) den Stand der DLLs der zu der Version der Hauptanwendung passt. Eventuell muss noch ein

Delphi-Quellcode:

git submodule update

gemacht werden wenn ich das richtig verstanden habe.

Wie man sieht, ist aber das Common Verzeichnis in jedem Projekt enthalten. Dort werden die gemeinsam genutzten Types deklariert. Es sind nur Pas Dateien die als Verweis eingebunden sind, kein wirkliches Projekt.

Wenn ich jetzt in einer der Common Files etwas ändere und einen Commit ausführe, dann weiß prinzipiell ja nur das Hauptprojekt etwas davon. Die DLLs sind immer noch nicht abhängig vom Common Verzeichnis, richtig? Und auch im Hauptprojekt werden die Änderungen nur protokolliert, wenn ich davon auch einen Commit absetze, oder?

Ich weiß leider nicht, wie ich das besser beschreiben soll. Vielleicht gehe ich das Thema ja auch falsch an. Nur will ich eben dafür sorgen, dass immer die richtigen DLLs zu der Version des Hauptprojekts ausgecheckt werden welches ich gerade bearbeiten will.


Ich habe auch gesehen, dass es Nested Submodules gibt, bin mir aber nicht sicher, ob mich das weiterbringt. Ich will natürlich auch den Aufwand, um an neue Versionen der Common Files zu gelangen wenn eine Änderung durchgeführt wird, so gering wie möglich halten und nicht erst bei allen DLL Projekten die Submodules aktualisieren müssen wenn ich mal eine kleine Änderung an einer der Common Files mache.


Wie löst ihr so etwas? Oder wie habt ihr eure Projekte strukturiert um nicht auf solche Probleme zu stoßen?

[Headbucket]

Hallo Aviator,

zunächst ist es gut, dass du einzelne repositories für die verschiedenen Projekte hast.
Wir haben bei uns oft sehr ähnliche Strukturen und lösen das ganze wie folgt:
- Common wird als Submodule in den jeweiligen Projekten eingebunden
- die DLLs werden als Submodule der Hauptanwendung eingebunden

So hattest du es ja auch schon angedeutet. Das ganze hat dann folgende Struktur:

Code:

L MainApp
  L Common
  L DLL 1
    L Common
  L DLL 2
    L Common
  L DLL 3
    L Common

Natürlich hast du dann das "Problem", dass du in jeder DLL das Submodule "Common" aktualisieren musst, wenn es Änderungen gibt. Das ist ja aber eigentlich auch richtig so. Denn diese Änderungen müssen im jeweiligen Projekt ja erstmal getestet werden. Das ganze lässt sich bei Bedarf ja aber auch automatisieren. Mit dieser Struktur hast du in jedem Fall die beste Rückverfolgbarkeit.

Zitat:

Zitat von Aviator (Beitrag 1416424)

Eventuell muss noch ein

Delphi-Quellcode:

git submodule update

gemacht werden wenn ich das richtig verstanden habe.

Das hast du richtig verstanden. Es gibt verschiedene git Clients (Sourcetree oder ähnliches), welche automatisch die Submodules updaten.

Zitat:

Zitat von Aviator (Beitrag 1416424)

Wenn ich jetzt in einer der Common Files etwas ändere und einen Commit ausführe, dann weiß prinzipiell ja nur das Hauptprojekt etwas davon. Die DLLs sind immer noch nicht abhängig vom Common Verzeichnis, richtig? Und auch im Hauptprojekt werden die Änderungen nur protokolliert, wenn ich davon auch einen Commit absetze, oder?

Verwendest du meine obrige Struktur, dann kannst du in jedem Projekt (MainApp, DLL1, DLL2, ...) das Common-Verzeichnis verändern. Danach einfach die Änderungen committen und pushen. Danach kannst du diese Änderungen logischerweise mit einem pull in den anderen Projekten einpflegen, testen und auch dort committen.

Grüße
Headbucket

[Aviator]

Danke für die Antwort. Ich habe mir fast gedacht, dass das Common Verzeichnis auch jeweils als (Sub)Submodule aller Submodules hinzugefügt werden muss. Das ist natürlich ziemlich viel Aufwand zu Beginn wenn man alle 5 Minuten an den Dateien rumschraubt. Ich bin alleiniger Entwickler an der Software und teste auch alles selbst.

Ich glaube zu Beginn werde ich es so machen, dass ich das Common Verzeichnis als übergeordnetes Verzeichnis der Submodules stehen lasse und ich die Änderungen nur einmal machen muss.

Ich werde das so auf jeden Fall im Hinterkopf behalten und dann ab der ersten Alpha oder Beta Version dann auf separate Submodules für das Common Verzeichnis umstellen. Weil ab dann ist es wirklich wichtig, dass alles zusammenpasst.


Oder gibt es für diese Art der Projektverwaltung noch andere Ansätze bzgl. GIT?

[freimatz]

Zitat:

Zitat von Headbucket (Beitrag 1416450)

Es gibt verschiedene git Clients (Sourcetree oder ähnliches), welche automatisch die Submodules updaten.

Beim pullen nur wenn man keinen Merge-Konflikt hat :wall:
Wir hatten mal submodule in Verwendung für externe Projekte aber inzwischen wieder aufgelöst. Der Aufwand war horrend hoch.
Wir haben alle Projekte in einem einzigen Repository.
Den Vorteil für jedes Projekt ein eigenes Repository zu machen sehe ich hier nicht. Das wäre dann gegeben wenn mehrere Haupt-Anwendungen Projekte gemeinsam verwenden.

[Der schöne Günther]

Den geteilten Code in einem eigenen Subrepo zu versionieren ist gut.

Aber weshalb Anwendung und ihre x DLLs alle einzeln versionieren wenn sie doch sowieso nur auf einem Stand zusammen funktionieren? Ich habe ein sehr ähnliches Projekt - Eine Hauptanwendung, zwei Handvoll Zusatz-DLLs, und diese teilen sich (allerdings nur sehr beschränkt) eine kleine Bibliothek. Ebendiese Bibliothek ist ein Subrepo, die Anwendung an sich mit ihren DLLs ein einzelnes Repo.

Das ist seit ungefähr vier Jahren so, alles bestens 8-)

[Aviator]

Zitat:

Zitat von Der schöne Günther (Beitrag 1417133)

Aber weshalb Anwendung und ihre x DLLs alle einzeln versionieren wenn sie doch sowieso nur auf einem Stand zusammen funktionieren?

Ist ein guter Punkt, ja. Anfänglich dachte ich, dass ein einzelnes Projekt (also eine Anwendung oder eine/mehrere DLL(s)) jeweils in einem separaten Repo besser aufgehoben wären.

Ich muss mir glaube ich doch nochmal Gedanken darüber machen.