Verwendung/Verwaltung von Bibliotheken mit GIT

Du könntest z.B. die Bibliotheken als Submodul deinem Projekt 
hinzufügen.

https://git-scm.com/docs/git-submodule

Torsten C. schrieb:
> Was ist die Frage?

Konkret geht es mir um die komfortable Nutzung, Wartung und 
Synchronisation  der Bibliotheken innerhalb der laufenden Projekte.

"Submodule" scheint das passende Stichwort zu sein. Vielen Dank für den 
Hinweis. Da werde ich mich mal einlesen.

Vorsicht, man man viel Quatsch damit bauen. Google mal “git submodules 
evil” ?

Grundsätzlich ist git ein Software Revisionssystem. Die Nutzung als 
Dependency/Library Management Tool ist nicht die Hauptaufgabe. 
Spätestens bei verschiedenen Versionen deiner Libs wird es spaßig.

Idealerweise nimmt man einen Paketmanager, in .net zb Nuget, in Python 
pip. C is etwas komplizierter, es gibt aber zb von ARM sogenannte 
CMSIS-Packs, die in eclipse oder Keil uvision geladen werden können.

Das nur Vorab, wir nutzen auch submodules, aber man muss sich bewusst 
sein, was man tut ;)

Git submodule kann man schon verwenden. Man muss aber genau wissen, was 
man tut. Eine Alternative dazu wäre noch git Subtree. Subtree ist etwas 
einfacher zu bedienen als Submodule.

Ich wollte mich noch einmal für eure Hilfe bedanken. Submodule sind 
genau das, was ich gesucht habe. Habe mich nun etwas eingearbeitet und 
nutze sie seit einigen Tagen. Bis jetzt ohne größere Probleme.

Liebe Grüße

TopperHarley

Ich denke es wird relativ fehleranfällig wenn man mehrere submodule in 
sein Projekt einbindet und Änderungen an den submodulen vornimmt. 
Wahrscheinlich kann es dann recht schnell passiert, dass man sich im 
falschen Unterordner befindet und/oder etwas versehentlich im falschen 
submodul oder Hauptprojekt commitet.

Submodules sind eine sinnvolle Sache (richtig angewandt zumindest) und 
wirken sich auf Strukturierung und Arbeit an den Projekten positiv aus.


- Submodules sind sinnvoll um Teile zu isolieren, die in mehreren 
Projekten eingesetzt werden sollen (oder können). Ohne submodules und 
einmal copy/paste in ein anderes Projekt driften die Kopien überraschend 
schnell auseinander. Das macht die Pflege dieser Teile (z.B. Bugfixing) 
sehr aufwändig.

- Submodules entkoppeln auch die Arbeit. Die Arbeit im Submodule streut 
nicht in die Historie des Hauptprojektes ein und bleibt somit klar 
isoliert. Ohne Submodules ist das Projekt meist ein waberndes Stück 
Etwas das von jedem, überall und dauernd geändert werden kann. Die Git 
Historie mit Branches und Merges wird schnell unübersichtlich. Big Ball 
of Mud. Aber manche Entwickler wälzen sich ja gerne wie die Schweine im 
Dreck :-)

- Submodules entkoppeln die Arbeit von Entwicklern. Drei Entwickler die 
in 3 verschiedenen Submodules arbeiten kommen sich garantiert nicht in 
die Quere. Im Gegensatz zu Branches des Hauptprojektes sind Merge 
Konflikte ausgeschlossen. Im Hauptprojekt können die Versionen der 
Submodules denkbar einfach aktualisiert werden (einfach ein Pull des 
Submodules), wenn deren Stand entsprechend solide ist. Bis dahin bleibt 
das Hauptprojekt und dessen Git Historie sauber.


Ich kann aus Erfahrung sagen, dass submodules helfen den Überblick zu 
behalten und viele Fehler zu vermeiden. Der Einsatz einer GUI zur 
Bedienung von Git kann allerdings hilfreich sein.