Gemeinsame Quellen verschiedener Projekte mit git verwalten

[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?

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

[Rollo62]

Hier ist das Thema mal sehr schön ausführlich erklärt ...

Rollo