Gemeinsame Quellen verschiedener Projekte mit git verwalten

**Headbucket**

Hallo zusammen,

wir sind aktuell dabei unsere aktuelle Versionsveraltung (JEDI VCS) auf git umzustellen. Dabei wollen wir gleichzeitig einige Dinge innerhalb unserer Projektverwaltung verbessern.

Nun haben wir ein konkretes Problem, wo wir nicht genau wissen, wie wir es mit git am besten lösen:
Wir haben oft das Problem, dass komplett verschiedene Projekte "Gemeinsame Units" verwenden. Diese Units liegen in einem Überordner und können z.B. den Umgang mit XML-Dateien oder SQLite regeln. Oft befinden sich aber auch einfach ganz allgemeine Funktionen in diesen "Gemeinsamen Units", welche man immer mal wieder benötigt.

Aktuell fügen wir diese "Gemeinsamen Units" entweder direkt dem Projekt hinzu oder fügen einfach bei Suchpfade den Ordner hinzu.

Findet man nun z.B. einen Bug innerhalb dieser "Gemeinsamen Units", dann wirkt sich diese Änderung natürlich unmittelbar auf alle Projekte aus, die diese "Gemeinsamen Units" verwenden. Das ist natürlich in den meisten Fällen gewünscht.

Würde man nun aber mal grundlegende Änderungen in diesen "Gemeinsamen Units" durchführen, dann hätte das natürlich auch negative Folgen auf alle Projekte.

Jetzt ist die Frage, wie wir diese Problematik in Zukunft lösen und vor allem, wie wir das Ganze in git abbilden.
Es wäre natürlich wünschenswert, wenn man beispielsweise mal in "Projekt 1" mit git einen alten Versionsstand zurücksetzen könnte. Dann wäre es natürlich auch toll, wenn die "Gemeinsamen Units" auf Wunsch diesen alten Versionsstand annehmen würden.
Ebenso wäre es kein Problem, wenn man bei einer Änderung in den "Gemeinsamen Units" bei jedem Projekt, welches diese "Gemeinsamen Units" verwendet eine Art Update machen muss, damit diese Änderungen auch hier wirksam werden.

Vllt habt Ihr aber auch noch eine bessere Idee zur Umsetzung?

Bei diesem Aufbau...

Repository1: Gemeinsame Units
Repository2: Projekt 1 (Link auf Gemeinsame Units)
Repository3: Projekt 2 (Link auf Gemeinsame Units)

...kann man zwar alles gut einzeln verwalten, es bestehen aber folgende "Probleme":
- Änderungen in den "Gemeinsame Units" haben direkten Einfluss auf Projekt 1 und 2.
- Bei einer Rücksetzung von Projekt 1 auf einen alten Stand ändert sich an den "Gemeinsamen Units" nichts.

Lassen sich meine Wünsche überhaupt Umsetzen? Oder habe ich vllt ein Brett vor dem Kopf und alles ist ganz einfach?

Ich würde mich sehr über Anregungen freuen! Vllt könnt Ihr mir auch beschreiben, wie Ihr es bei Euch löst.

Grüße
Headbucket

**Sherlock**

Hey! Ich hab auch mal JediVCS verwendet...sogar noch in der Zeit als es FreeVCS hieß! Gratuliere, daß Du so lange durchgehalten hast.

Bei Git heißt das was Du brauchst Submodule:

https://git-scm.com/book/en/v2/Git-Tools-Submodules
Kurz gesagt bindest Du ein Git Projekt in ein anderes ein. Damit bleibt die Versionierung erhalten und der Versionsstand des eingebundenen Projekts wird am Versionsstand des einbindenden Projekts gebunden. Das bedeutet, daß immer konsistente Versionen miteinander arbeiten.

Sherlock

**Rollo62**

Ja richtig.
Aber ich habe es noch nicht getestet, weil ich schon öfters gelesen habe man muss erst alle SubModules
committen bevor man das HauptVerzeichnis commited.

Das scheint mir nicht ganz das zu sein wonach ich suche.

Oder gibt es da einen "einfachen" Recursive-Commit der das alles ohne viel Batch-Datei auflösen kann ?

Rollo

**Der schöne Günther**

Ich mache fast nichts mit git, nur Mercurial. Die Begriffe sind sicher anders, aber ich glaube meist sind die beiden sehr ähnlich.

Eigentlich ist das doch haargenau das, was man mit Subrepos (git=submodule?) macht. Die Libraries gibt es als Subrepo in deinen Projekten.

Wenn man in Projekt A einen Bug in Library X fixed pusht man das auf den Server zurück (dort liegt Library X als eigenständiges Repo). Projekt B hat ebenfalls Library X als Subrepo und kann sich die Änderungen mit einem Klick holen. Muss es aber nicht, es kann auch seinem Stand bleiben.

Währenddessen nutzt Project C auch die Library X, allerdings hat es an der Library etwas herumgedoktert, spezielle für seine Zwecke. Das Unter-Repo X hat hier einen privaten Seitenzweig der nicht zurück auf den Server gepushed wird. Für den Fall dass man in Projekt C einen Bug in X fixed und den zurückspielen möchte

Das Repo von Projekt A/B/C merkt sich immer auf welchem Stand sein Unterrepo "Library X" ist. Gehst du also einen Monat zurück ist deine Library X dort auch wieder auf dem passenden Stand.

In Git geht das wahrscheinlich genauso...

**Rollo62**

Vielleicht ist es ja auch korrekt so.

Sources
--Maín1
----Lib1
----Lib2
--Maín2
----Lib1
----Lib2

Ich hatte nur an mehreren Stellen gelesen das man erst Lib1/2/... committen MUSS,
bevor man Main commited.
Wenn verschiedene Main Projekte automatisch verschiedene Stände von Lib vrwalten könnten wäre das natürlich
auch super.
Aber ich pflege in der Regel alle Main Projekte wenn es änderungen in den Libs gibt.

Die Frage wäre wie verhält sich GIT in den verschiedenen Situationen wenn ich nur in den Main-Sourcen commite.
- Maín2 geändert, Lib1 alt --> Main2 commited --> wird auch Lib1 einen neuen Commit bekommen ?
- Maín2 alt, Lib1 geändert --> Main2 commited --> wird auch Lib1 unter Main1 einen neuen Commit bekommen
(und damit praktisch Main1 geändert )?
- Wenn alle Projekte sauber ich möchte ich quasi Sources commit all machen, falls es soetwas gibt.
Damit keine unterschiedlichen Lib1/2 Versionen mehr da sind.

Das wird sicher alles super funktionieren, aber womögich gibt es spezielle Regeln die man beachten sollte.
Vielleicht gibt es ein einfaches Tutorial dazu ?
Im Moment habe ich noch alle Projekte separat und nicht als SubModules, das erscheint mir im Moment noch sicherer
weil ich weiss was passiert.
Hat aber dann Redundanzen.

Rollo

**Sherlock**

Ich nutze auch nicht git, sondern Mercurial und da funktioniert es genauso wie man es erwartet, und wie es unser Schönling beschrieben hat. Wenn man die Kommandozeile benutzt packt man immer den Parameter -S bzw. --subrepos hinten dran, damits auch wirklich klappt. Aber die grafischen Frontends wie TortoiseHg und SourceTree machen es automagisch richtig. In der Tat wird über Subrepositories geschrieben, sie seien der letzte Ausweg. Ich glaube aber das liegt daran, daß die Leute nicht mit geteilten Codebibliotheken arbeiten, ich sehe nämlich nicht, wie das anders zu lösen wäre.

Sherlock

**mquadrat**

Ich würde aus den gemeinsamen Units ein eigenes Projekt machen und das dann jeweils in der IDE installieren. Damit hätte man einen komplett eigenen Versionsbaum, so dass Projekt A eine Abhängigkeit auf Version 1 des neuen Packages hat und Projekt B eine Abhängigkeit auf Version 2 des neuen Packages. Kann ja mal sein, dass es Breaking Changes oder so gibt.

Anders formuliert: Interne Packages würde ich so behandeln, als wären es externe.

**Valle**

Hi,

wir verwenden Git und auch Submodule.

Wenn du Änderungen innerhalb der Submodule vornimmst, dann musst du zwei Commits machen, das ist korrekt. Und auch richtig so. Denn ein Submodul ist immer über einen bestimmten Commit in sein Eltern-Repository eingebunden. Beim Clone deines Projekts ist in Git also nicht nur gespeichert, welches Submodul benötigt wird, sondern auch welcher Commit des Moduls.

Solltest du eine Änderung am Modul vornehmen wollen, so musst du mehrere Schritt machen. Zuerst machst du ein Checkout (Branchwechsel) Im Submodul. Submodule sind standardmäßig in keinem Branch sondern checken den Commit direkt aus. Dann machst du deine Änderung und commitest sie in das Submodul. Ein neuer Commit-Hash entsteht. Zuletzt gehtst du wieder in das Eltern-Repository (dein Hauptprojekt) und musst (kannst!) dort die neue Version des Submoduls bekannt machen. Du fügst also via git add das Modul der Staging Area hinzu und commitest dann. Wir schreiben meist nur "neue Lib" als Commit-Message.

Da alle anderen Projektrepositories ja auch an einen Commit gebunden sind, erhalten diese die Ändeurngen nicht sofort. Du hast hier also die Möglichkeit, Änderungen erst zu testen. Wenn die Ändernungen getestet und stabil sind, gehst du bei allen anderen Repositories genauso vor. Checkout im Submodule, Add, Commit, Push.

Solche Änderungen sind bei uns nicht so häufig und der Aufwand zur Verwaltung ist auf jeden Fall gerechtfertigt. Wir haben nunmal solche Abhängigkeiten und diese verwalten sich einfach nicht von selbst. Änderungen die wir in den Hauptrepositories vornehmen sind von von Submodulen vollkommen unabhängig und benötigen kein weitere Beachtung dieser. Du editierst, addest, committest und pushst wie üblich.

Hoffe das hilft dir weiter?

**Headbucket**

Hallo,

vielen Dank für die zahlreichen Antworten.

@Sherlock
Ja das gute alte JEDI

Wird eine ziemliche Umgewöhnung nun nicht mehr alles "sperren" zu können mit git.

Ich hatte geahnt, dass es mit Submodulen möglich ist - hatte es aber noch nicht getestet. Nachdem der Begriff hier ein paar mal gefallen ist, habe ich heute Vormittag mal ein Beispielprojekt gemacht und muss sagen: Es funktioniert eigentlich genauso, wie ich es wollte.

Die Vorgehensweise ist dabei genauso, wie Valle es geschrieben hat. Vielen Dank dafür

Ich habe also zunächst die gemeinsamen Units angelegt: Nennen wir sie mal Common.
Daraus habe ich dann natürlich ein repository erstellt und dieses auf einen Server geschoben.

Danach habe ich eine beliebige Anzahl an Projekten, welche diese gemeinsamen Units nutzen möchten. Nenn wir sie: Project1 und Project2
Nachdem ich die repositories für die beiden Projekte angelegt habe, habe ich die gemeinsamen Units über

markieren

Code:

git submodule add <URL> <Pfad/Name fuer Unterverzeichnis>

hinzugefügt.
Die gemeinsamen Units wurden nun jeweils in einen Unterordner von den Projekten kopiert.
Danach musste ich natürlich nochmal die beiden hauptprojekte Project1 und Project2 committen.

Ändere ich nun etwas an Common in Project1, dann bekommt Project2 erstmal nichts davon mit - gut so.
Erst, wenn ich in Project2 in das Unterverzeichnis zu Common wechsel, dann kann ich mit git

markieren

Code:

git fetch <Name>

die Aktualisierungen vom Server holen.
Danach noch Project2 comitten und alles ist gut.

Genau so wollte ich es eigentlich.
Änderungen der gemeinsamen Units werden somit in den einzelnen Projekten nicht automatisch übernommen.
Außerdem kann ich bei den einzelnen Projekten jederzeit auf einen alten Stand zurück und habe dann auch die passenden gemeinsamen Units zu diesem Stand.

Super

Dann gibt es jetzt wohl keinen Grund mehr auf git zu verzichten.

**Uwe Raabe**

Zitat von Sherlock:

In der Tat wird über Subrepositories geschrieben, sie seien der letzte Ausweg. Ich glaube aber das liegt daran, daß die Leute nicht mit geteilten Codebibliotheken arbeiten, ich sehe nämlich nicht, wie das anders zu lösen wäre.

Diese "feature of last resort" Keule kommt halt aus einer Ecke, in der Delphi mit seiner 1-Exe Philosophie gänzlich unbekannt ist. Abhängigkeiten zwischen Modulen werden dort über Tools wie NuGet gelöst und die Module lassen sich auch in der Regel unabhängig voneinander erstellen. Der klassische Delphi-Programmierer möchte allerdings die gesamten Sourcen für ein Release in einem definierten Zustand haben, das Ganze dann auch noch in projekt-relativen Pfaden und dafür sind die Mercurial Subrepos einfach das Mittel der Wahl. Ich arbeite nun schon viele Jahre damit und nach einer kurzen Umgewöhnung direkt nach dem Umstieg von Subversion mit seinen Externals funktioniert das einfach tadellos. Mittlerweile ist die Performance beim Push mit Subrepos auch viel besser als noch zu Anfang, so daß deswegen auch keine speziellen Tricks mehr angewandt werden müssen. Selbst wenn man mal versehentlich (oder absichtlich) in der Projektkopie des Subrepos rumwerkelt, lässt sich das dank der genialen Merge-Eigenschaften in Mercurial in der Regel problemlos wieder gerade rücken.