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

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

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

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...

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

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