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?
Du könntest z.B. die Bibliotheken als Submodul deinem Projekt hinzufügen. https://git-scm.com/docs/git-submodule
Was du suchst sind Submodule. Ich habe damit aber bisher keine praktische Erfahrung gemacht. https://git-scm.com/book/de/v1/Git-Tools-Submodule Der erste Satz klingt da fast wie dein Post.
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.
:
Bearbeitet durch User
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.
git submodule passt schon für die Aufgabenstellung. Nimm dir aber Zeit für die Einarbeitung. Die Bedienung ist am Anfang etwas fummelig.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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
Wo sollen denn die Probleme bei SubModulen liegen? Beispiel?
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.
Falls die Projekte nicht zu groß sind spricht auch nichts dagegen alles in einem git-repo zu lassen. Google-Stichwort "monorepo".
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.