GitHub-Interdependenzen

BAGZZlash

Moderator
Teammitglied
Ich habe ein Programmierprojekt A (in C#, mit Visual Studio 2019), das bei GitHub als Repo liegt. In diesem Projekt benutze ich drei Klassen B, C, und D (alle ebenfalls von mir), die jeweils selbst in ihren eigenen Repos gepflegt werden. Alle Repos sind öffentlich.

Die GitHub-Intergration in VS ist eigentlich vorbildlich. Nun suche ich aber nach einer (möglichst frickelarmen) Lösung, sodass ich beispielsweise Klasse D in ihrem Repo pflegen kann (beispielsweise neue Methoden hinzufügen oder Bugs fixen), und die Änderungen sofort in Projekt A zur Verfügung stehen. Mich nervt einerseits, immer wieder den Code kopieren zu müssen, außerdem fürchte ich andererseits Versionswirrwarr.

Gibt's dafür nix?
 
Du könntest rein theoretisch die klassen b,c,d als nuget packet über eine github action bei jedem commit/pull request bauen lassen. Im projekt A dann nen dependabot laufen lassen und die packages so updaten
 
Mir würden ansonsten noch Git Submodules in den Sinn kommen:

 
Das klingt tatsächlich beides gut. Nuget Package wäre charmant, weil das Ganze open source wird und hoffentlich nachher andere Entwickler tatsächlich für unsere Plattform entwickeln (und dafür die Klassen C und D brauchen). Submodules scheint etwas eleganter und weniger hacky zu sein. Ich probier' das, vielen Dank! :)
 
Ich hab jetzt zwei Stunden mit Submodules rumgespielt. Leider klappt das nicht so, wie ich mir das vorstelle. Was ich will, ist ja, dass wenn ich z.B. für Klasse C in deren eigenem Repo beispielsweise einen Bug fixe (oder sonstige Änderungen am Code vornehme), diese Änderungen nach einem Sync in Projekt A zur Verfügung stehen.

Ich habe jetzt den Eindruck, dass man über Submodules zwar Repo C in Repo A einbetten und dort auch verwenden kann, aber keine echte Verzahnung stattfindet, so wie ich das will. Oder bin ich zu blöd?
 
Ehrlich gesagt ist es schon zu lange her, dass ich mich flüchtig mal mit Submodules auseinandergesetzt habe, um dir da großartig weiterzuhelfen.

Was wäre denn eine echte Verzahnung bzw. was fehlt dir genau?

Aber ja, kann gut sein, dass Submodules nicht so wirklich das richtige sind.
Ich erinnere mich noch, dass ich meinen Use Case für Submodules damals nach kurzer Zeit auch als recht umständlich und eher weniger brauchbar wieder aufgegeben hatte.
 
Repo C wird halt in Repo A kopiert, ist fortan darin enthalten und kann verwendet werden. Schön, ich will aber, dass in A nicht einfach eine Kopie von C angelegt wird, sondern dass von A aus auf C "verlinkt" wird, sodass externe Änderungen in C sofort in A einfließen. Hm.
 
Ja genau, aber externe Änderungen in C kannst du doch jedesmal per Sync einpflegen und damit in A einfließen lassen?
Komplett automatisch wird das wahrscheinlich nicht funktionieren und wäre ja auch irgendwie blöd, wenn bei jedem Auschecken des Repos A direkt die neueste Version von C gezogen würde, weil du dann wiederum keine Kontrolle über die Versionen hättest.

Über GitHub Actions kann man dann noch versuchen, diesen Sync automatisch ablaufen zu lassen... Ach so, wait. Werden Submodules immer nur lokal gezogen oder ist nach einem Sync auch die Versionshistorie angepasst, sodass man bei GitHub sieht, dass die neueste Version von C eingebettet ist?
Weil sonst würde das natürlich nichts bringen.

Du siehst, mir sind Submodules einfach so aus der Vergangenheit noch ein Begriff gewesen und schienen ganz passend.
Vielleicht ist ein Workflow mit Packages und GitHub Actions tatsächlich besser.
 
Ich weiß nicht, ob man das mit git sinnvoll abbilden kann, ich denke cherrypick von einem Repo ins andere geht, da müsstest du das aber ggf. wiederholen. Wäre vielleicht ein eigenes lokales nuget-Repo eine Option?
 
Zurück
Oben Unten