GIT source einer Ebene höher versionieren?

[Kostas]

Hallo Zusammen,

ich habe eine Projektgruppe die sie teilweise den gleichen source nutzen. Gibt es eine Möglichkeit ein Projekt außerhalb des Projektverzeichnisses mit zu versionieren?

Beiepiel:
C:\Projektgruppe\Projekt1
C:\Projektgruppe\Projekt2
C:\Projektgruppe\sharedFiles

Projekt1 soll versioniert werden incl. sharedFiles
Projekt2 soll versioniert werden incl. sharedFiles

Gruß Kostas

[Der schöne Günther]

Git kümmert sich nicht um (Delphi-)Projekte, sondern um Verzeichnisse.
Normalerweise würdest du

Delphi-Quellcode:

sharedFiles

als eigenes Repo haben, als Unterordner in jeweils Projekt1 und Projekt2.

Dann könnten die beiden auch völlig frei mit unterschiedlichen Versionen arbeiten.

Lesestoff:
https://git-scm.com/book/en/v2/Git-Tools-Submodules

[Uwe Raabe]

Kurze Antwort: Jain

Theoretisch ginge das, in dem man das sharedFiles Repo in den beiden Projekten als Submodule anlegt, aber das hat einen gravierenden Nachteil: Ein Update von Projekt1 auf eine Version X würde auch die sharedFiles auf die zu X passende Version setzen. Wechselt man dann auf Projekt2 und macht ein Update auf Version Y würde sharedFiles auf der passenden Version für Y stehen. Öffnet man nun Projekt1 passt die Version in sharedFiles womöglich nicht mehr dazu.

Besser ist es, wenn beide Projekte ihren eigenen Clone von sharedFiles haben.

[Kostas]

Zitat:

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

...
Dann könnten die beiden auch völlig frei mit unterschiedlichen Versionen arbeiten.

Lesestoff:
https://git-scm.com/book/en/v2/Git-Tools-Submodules

Genau dass soll unbedingt verhindert werden. Beide Projekten müssen die gleichen sharedFiles nutzen und dürfen auf keinen Fall auseinander laufen.
Erreiche ich das durch deinen Vorschlag mit Submodules, hab mich damit noch nicht beschäftigt.

Gruß Kostas

[Der schöne Günther]

Ok, wenn das alles zwingend zusammenhängt und beide Projekte den gleichen Stand der Bibliothek verwenden müssen, dann ist das doch ein großes Repo "Projektgruppe".

Falls "Projekt1" und "Projekt2" bereits eigenständige Repos sind, könnte "sharedFiles" zu einem dritten, eigenständigen Repo machen und dann "Projektgruppe" als "Über-Repo" oben drüber anlegen. Das stelle ich mir aber wenig spaßig vor, weil du dann jede Änderung praktisch doppelt versionierst. Bei jeder Änderung in "Projekt1" musst du dann nochmal separat das "Projektgruppe"-Repo aktualisieren. Oder vielleicht ist das gar nicht so schlecht, und du aktualisiert das in "Projektgruppe" nur für Releases.

Vielleicht muss man da auch einfach mal ein bisschen spielen um das passende für den eigenen Geschmack zu finden.

Meiner wäre das denke ich nicht. Ich würde "Projekt1" und "Projekt2" in einem Repo zusammenverwalten und "sharedFiles" als Subrepo dort drinnen halten. Dann benutzen beide immer den gleichen Stand von "sharedFiles".

[Uwe Raabe]

Zitat:

Zitat von Kostas (Beitrag 1505503)

Beide Projekten müssen die gleichen sharedFiles nutzen und dürfen auf keinen Fall auseinander laufen.

Das ist eigentlich ein deutliches Kriterium, dass beide Projekte in dasselbe Repo gehören.

[himitsu]

klar, du kannst erstmal in Beiden das selbe Submodul einbinden, aber niemand schreibt dir vor, dass es der selbe Branch sein muß.

Da könnte man dann entweder jeweils manuel das Submodul updaten (commit+push oder pull) und den Submodul-Link inkl. der GUID des aktuellen Commits im jeweiligen Hauptrepo committen.
Jedesmal, wenn du das Submodul aktualisierst, mußt du um Hauptrepo die neue GUID mit committen.
(das ist im Prinzip das Standadvorgehen, seitens GIT ... bei SVN konnte man das einfacher verlinken, z.B. sagen das der aktuelle Stand zu einem Tag oder was Anderem genommen werden soll ... da nam sich das Hauptrepo automatisch den jeweils aktuellen Stand ... hat Beides Vor- und Nachteile)

Alternativ kannst auch mit Branches je Hauptrepo arbeiten, beim Checkout wäre dann jeweils der letzte/vorherige Stand passend zum Commit-Date der Hauptrepos zugehörig.
So kann es auch mal etwas auseinander laufen, wenn einer der Hauptrepos noch nicht mit dem aktuellen Submodul kompatibel ist.

Bei Branches wäre mit aktuellem Hauptrepo immer der jeweils aktuelle Commit im jeweiligen Branch zugehörig.
Nur beim zurückgehen kann man sich dann überlegen, ob man die committete GUID oder einfach das Commit-Date des Submodules nimmst