Gemeinsame Quellen verschiedener Projekte mit git verwalten

[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

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

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.

[Rollo62]

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

Rollo

[Headbucket]

Ich muss meinen "alten" Thread nochmal hochholen, da sich im laufendem Betrieb noch ein paar Schwierigkeiten gezeigt haben. Vielleicht hat Jemand eine Idee, wie wir das besser lösen könnten. Hier mal ein Beispiel zur Veranschaulichung:

Ich habe also meine gemeinsamen Quellen, welche zu verschiedenen Themenbereichen zahlreiche Units enthalten:

- Common Sources
- Lib A (enthält 50 Units)
- Lib B (enthält 50 Units)
- ...
- Lib Z (enthält 50 Units)

Ich habe nun zwei Möglichkeiten: Ich lege für jeden Teilbereich ein eigenes Repository an oder ich lege für die kompletten Gemeinsamen Quellen ein Repository an.
Egal wofür ich mich entscheide, in meinem späteren Projekt habe ich dann folgendes Problem:

Ich benötige z.B.
- 2 Units aus Lib A
- 5 Units aus Lib B
- 1 Unit aus Lib E
- 2 Units aus Lib Z

Dazu kann ich natürlich die entsprechenden Repositories als Submodule einbinden. Allerdings mit relativ viel Overhead. Ich binde also wegen 10 Units ca. 1000 in das Projekt ein. Damit könnte ich sicher noch leben. Wenn nun aber an den 990 Units, welche ich nicht in meinem Projekt benutze etwas geändert wird, dann bekomme ich diese Änderungen ja auch in meinem Projekt mit, wenn ich prüfe, ob es Änderungen in den Submodulen gibt.

Ich habe nun gesehen, dass es dafür eventuell auch schon eine Lösung gibt? Ich habe hier Dinge wie sparse checkout und splitting gefunden.
Hat damit eventuell schon jemand Erfahrungen gesammelt?
Wenn es also irgendwie geht, dass ich nur bestimmte Units aus den gemeinsamen Quellen auschecken kann, dann wäre das ideal. Natürlich sollte ich dann auch weiterhin Änderungen an diesen gemeinsamen Units mitbekommen.

Hier würde ich mich über Erfahrungen von euch freuen!

Grüße
Headbucket

[Sherlock]

Tja, das hört sich nach einem sehr speziellem Fall an. Normalerweise hat man ja nur die Units in einem Repository, die auch zusammen gehören. Falls es also Änderungen gibt, sollten die auch zusammengehalten werden. Es spricht andererseits nichts dagegen, die Subrepositories zu schachteln...nur der eigene Überblick, vielleicht. Eventuell hilft das weiter. Oder Du machst Dir nochmal generell Gedanken über Deine Repository-Strukturen. Ich habe das Gefühl es gibt leider nicht DIE eine Lösung für Dein Problem, versuch Dir nochmal die "best practices" für git zu vergegenwärtigen. Ein Ausgangspunkt dafür vielleicht hier: http://stackoverflow.com/questions/1...git-repository


Viel Erfolg!

Sherlock
- der das Gefühl hat, heute ist VCS-Montag