Gemeinsame Quellen verschiedener Projekte mit git verwalten

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