Guten Morgen Forum! Ich überlege derzeit alle Mikrocontroller-Sourcen mit GIT zu versionieren. Dabei möchte ich bestimmte Komponenten bzw. Librarys getrennt als "Gemeinsame Komponenten" oder "Common Components" getrennt verwalten. Beispiel: Ich erstelle ein neues Projekt und lege ein Responsitory an. In das Verzeichnis soll jetzt meine LCD-Library aus einem anderen Repo geshared werden. Diese Library kann ich nun in das neue Projekt einbinden. Wenn ich an den LCD-Routinen was verändere möchte ich das wieder global adden/commiten, so das die änderungen ggf. in anderen Projekten schnell einfließen können. Uff, ist das denglisch .... Geht das so einfach mit GIT? Gibt es da was zu beachten? Vg! K.
Ja geht, mit git submodule add <repo-url> kannst du deine library mit einbinden. Weitere Infos siehe git submodule.
Ich rate von der Verwendung von git submodule ab. Bau doch die gemeinsamen Sachen in eine Static Library (.a), installiere die gemeinsam genutzen Header und diese Library irgendwo hin, und linke dagegen.
Hi Katafish, genau sowas wollte ich auch mal in git umsetzen. Sogern ich git auch mag, ich muss leider sagen, bei diesem Thema sind andere Versionsverwaltungen stärker. git submodule hab ich auch ausprobiert, klappt auch irgendwie, aber ist bisl fummelig. Hab aber dann auch ned soo viel Zeit da reingesteckt.
Sven B. schrieb: > Ich rate von der Verwendung von git submodule ab. Was genau spricht dagegen? Magst Du das mal erläutern?
Klaus schrieb: > Sven B. schrieb: >> Ich rate von der Verwendung von git submodule ab. > > Was genau spricht dagegen? Magst Du das mal erläutern? Es gibt kein so richtiges Totschlagargument, aber wie lex sagte, es ist einfach irgendwie immer fummelig. Du brauchst mehrere Befehle beim Klonen um ein funktionierendes Repo zu erhalten, du brauchst mehrere Befehle um das Repo zu aktualisieren, wenn du irgendwas davon vergisst passieren u.U. komische Dinge. git-describe gibt dir keine verlässliche Beschreibung des Zustands der Repository mehr. Immer wenn ich mit git submodule zu tun hatte traten irgendwelche unerwarteten Probleme auf (und ich bin da nicht allein, du kannst ja mal ein bisschen rumgoogeln). Und es bringt dir einfach nicht wirklich einen Vorteil in diesem Fall gegenüber der Static Library-Lösung. Ich würde sogar behaupten es bringt dir nichtmal wirklich einen klaren Vorteil gegenüber dem einfach die ganze Lib in das Repo zu kopieren. So gut wie du "git submodule update" tippen kannst, kannst du auch die seitdem passierten Änderungen in der Bibliothek als Patches in deine Kopie reinziehen. Und dann ist es wenigstens einfach und intuitiv zu benutzen und du kannst trivial lokale Anpassungen für ein einzelnes Projekt vornehmen.
:
Bearbeitet durch User
Wenn man sich einmal damit befasst hat wie das mit dem submodulen läuft klappt das eigentlich sehr gut. Ja, ich brauche nicht ein kommando um ein repository auszuschecken, ich brauch 2. Das bringt aber niemanden um hoffe ich. Das was man verstehen musst ist das man aus sicht des hauptrepositories sumbodule wie eine einzelne datei behandelt wenn man den "inhalt" ändert. Wenn du also z.b. deine Lib in einer neuen version releast hast dann checkst du im submodul ordner den passenden tag, branch, oder commit aus, wie auch immer du das handlest. wenn du jetzt git im haupt-repository nach dem status des repositories fragst wirst du feststellen das sich das submodul verändert hat. das kannst du jetzt commiten. Damit comittest du aber nicht die geänderten Dateien sondern nur den Zeiger des Submoduls auf den aktuellen Stand.
Also mit dem --recursive reicht bei mir auch ein Kommando um alle submodule auf einmal mit auszuchecken. Auch bei mehrfach verschachtelten Repositories.
Clemens N. schrieb: > Also mit dem --recursive reicht bei mir auch ein Kommando um alle > submodule auf einmal mit auszuchecken. Auch bei mehrfach verschachtelten > Repositories. Das ja, aber beim initialen clone musst du dann anschließend noch dein git submodules... ausführen. Wenn das aber eon ko-kriterium ist...
Ich grab den Fred mal wieder raus. Das Thema ist immer noch aktuell. Aufgrund von wenig Zeit geriet das etwas in den Hintergrund. Nun hab ich mich mal mehr mit GIT auseinander gesetzt. Die Grundlegende Funktion und das Handling sind soweit klar. Thema submodule: Static Libraries finde ich für mich weniger interessant. Da nehme ich lieber etwas mehraufwand in Kauf und nutze submodules. Um das auszuprobieren habe ich ein fiktives Testprojekt erstellt und drauf los getestet. Dabei sind nun Fragen aufgekommen, die ich mit Hilfe der Man-Pages nicht beantworten konnte. 1. Speichert GIT die Pfade zu dem Ursprung des Submodules absolut oder relativ? 2. Änderungen in Submodules: Projekt A enthält eine Biliothek, welche ich als Submodule in Projekt B einfügen möchte. Wenn sich die Sourcen in Projekt A ändern, kann ich diese mit pull im Projekt B aktualisieren. Nun fällt mir aber auf, während ich Projekt B bearbeite, das ein Bug in dem submodule enthalten ist. Ich behebe den Bug im Projekt B und möchte die Änderungen zurück zu Projekt A senden. Ein normaler push geht nicht, da Projekt A und B beide im Master-branch sind. Kann ich per push sagen, das die geänderten Sourcen aus dem submodule von Projekt B in einen neuen Branch in Projekt A eingefügt werden? Denn dann kann ich anschließend bei Projekt A den Änderungs-Branch mit dem Master mergen. Vg! Katatafish
Und genau diese Szenarien sind (für mich) unheimlich frickelig mit submodulen zu handhaben. Eine alternative sind wohl subtrees, hier mal eine Übersicht https://gist.github.com/kvnsmth/4688345.
Foobar schrieb: > Und genau diese Szenarien sind (für mich) unheimlich frickelig mit > submodulen zu handhaben. Genau so ist es. Deshalb der Rat, keine Submodules zu benutzen. ;p
Katafish schrieb: > Nun fällt mir aber auf, während ich Projekt B bearbeite, das ein Bug in > dem submodule enthalten ist. Ich behebe den Bug im Projekt B ... Nein! Bugreport für Projekt A erstellen mit einem Patch zur Behebung als Attachment und dann auf das neue Release von Projekt A warten und hoffen dass das Projektteam A den Bug behoben hat ;-)
wenn du in 2 projekten ne lib nutzen willst dann brauchst du 3 repos um das sinnvoll zu machen: 1: repo für projekt a 2: repo für Projekt b 3: repo für lib x dann kannst du pib x als submodule in projekt a und projekt b auschecken.
Das ist ein zweischneidiges Schwert. Ich bin mittlerweile wieder dazu übergegangen jeweils Kopien der fraglichen mehrfach verwendeten Dateien in ihrem damaligen Zustand direkt in das Repository des jeweiligen Projekts einzuchecken, die können im Einzelfall auch mal deutlich auseinander laufen, nicht alles ist so generisch dass man es ohne Anpassungen überall benutzen kann, oftmals hat da der Pragmatismus gesiegt. Das Vorgehen halte ich unter diesen Umständen für einfacher handhabbar als noch in jedem Projekt zwei bis fünf verschiedene Submodul-Repositories zu haben mit zig verschiedenen Branches, praktisch für jedes Projekt seinen eigenen Branch damit nichts versehentlich verrutschen kann. Stattdessen arbeite ich intensiv mit Meld, pflege für jede solche "lib" oder mehrfach nutzbare Datei genau eine Master-Version in ihren eigenen Repository die immer alle für gut befundenen Verbesserungen enthält und die schmutzigen Hacks für einzelne Projekte bleiben in den einzelnen Projekten. Und jedesmal wenn ich ein uraltes (aber noch produktives) Projekt wieder anfassen muss weil irgend ne Kleinigkeit verändert werden muss entscheide ich von Fall zu Fall welche Teile der mittlerweile angefallenen Verbesserungen der gemeinsam verwendeten Libs gebrauchen kann (oder will) und gefahrlos reinmergen kann ohne mich in eine tagelange Refactoring und Test-Hölle wegen geändertem API begeben zu müssen, nur weil ich eigentlich nur schnell zwei Zeilen ändern wollte.
:
Bearbeitet durch User
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.