Hallo zusammen,
ich nutze seit einiger Zeit GIT zur Versionsverwaltung meiner
Softwareprojekte (privat und beruflich). Dabei stoße ich immer wieder
auf ein Problem und hoffe es gibt dazu eine einfache Lösung. Angenommen
ich habe mehrere Bibliotheken, welche sich jeweils in einem eigenen
GIT-Repo befinden, wie z.B.:
UART-Repo
CAN-Repo
LCD-Repo
usw.
Diese Bibliotheken werden in mehreren Projekten verwendet und wachsen so
mit der Zeit bzw. werden laufend verbessert.
Wie gehe ich hierbei am besten vor? Meine Wunschvorstellung wäre, dass
ich die aktuellste Version der jeweiligen Bibliothek in mein aktuelles
Projekt clonen, Änderungen vornehmen und diese anderen Projekten
bereitstellen kann.
Habt ihr hierzu einige Tipps?
Danke für eure Hilfe!
TopperHarley schrieb:> ich nutze seit einiger Zeit GIT zur Versionsverwaltung meiner> Softwareprojekte (privat und beruflich).
Dann hast Du doch Erfahrung mit pull und push.
GIT ist es egal, ob das ein Softwareprojekt ist oder eine UART-Lib.
Was ist die Frage?
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 ;)
Sinnvoll sind Submodule eigentlich nur, wenn man externe Abhängigkeiten
im Quelltext im eigenen Projekt nutzen will. Das kommt dem, was du tun
willst, zwar schon recht nahe, dann aber doch nicht.
Da du die Kontrolle über die Bibliotheken hast und sie
höchstwahrscheinlich zusammen mit deinem Projekt entwickelst, handelst
du dir mit Submodules wahrscheinlich mehr Ärger als Nutzen ein.
Du kannst dir stattdessen ja mal "repo" anschauen, dort besteht ein
Projekt schlicht aus mehreren Git-Repositories, die du in einer
XML-Datei angibst (inklusive Revision, Branch oder Tag). Android nutzt
das, weil Submodules doof sind.
Von Submodulen würde ich die Finger lassen (einfach mal googlen warum).
Man kann ohnehin nur ein Submodul anlegen.
Ich denke auch das hier das "repo" von Google das richtige Tool ist.
Da gibt es eine Manifext-XML, in der alle GIT Repos eingetragen sind.
Man gibt dann das Kommando "repo sync" ein und alle Repos aktualisieren
sich.
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 habe die beste Erfahrung mit einem Workspace Script gemacht. Also
einem Shell oder Python Script welches sich um alle dependencies
kümmert. Grade für C(++) sehr hilfreich da man eventuell genau eine
bestimmte Version einer Bibliothek benötigt, oder die version speziell
gebaut werden muss (z.B. einen bestimmten Profiling Build, der einen
ganzen Rattenschwanz an configure Argumenten braucht, oder eine
Spezielle Version die du aus einem git tag oder branch auschecken
kannst)
Somit habe ich dann ein Workspace Repository was das Checkout/Build
Script enthält, welches alle dependencies auscheckt, korrekt baut und
dann noch das eigene Projekt auscheckt und Konfiguriert für diese
Dependencies. Außerdem können in das Repository dann noch weitere
Scripts z.B. für spezielle Builds oder cleanup, etc. Das tatsächliche
Projekt landet dann in einem anderen Repository und wird von dem Build
script ausgecheckt.
Ansonsten sind wohl (wie bereits erwähnt) Submodules dein Freund
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
Christoph M. schrieb:> Wo sollen denn die Probleme bei SubModulen liegen? Beispiel?
Es ist erstaunlich einfach, seine Sourcen in einen inkonsistenten
Zustand zu bekommen, so dass man unbemerkt den aktuellen Quelltext mit
einer alten Bibliothek baut oder umgekehrt. Erklärungen findest du bei
Google.
Wenn man keine Fehler macht oder die Nutzung der Repositories
größtenteils automatisiert, sind Submodule kein Problem.
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.
