Git/GitLab: Großprojekt mit Plugins - wie viele Projekte

[TheMiller]

Hallo,

vorab - ich wusste nicht genau, wie ich den Titel aussagekräftiger gestalten konnte.

Ich habe eine kleine Grundsatzfrage: Wir stiegen vor kurzem auf Git bzw. dem selbstgehosteten Gitlab um. Nun möchten wir ein Projekt importieren, an dem wir wieder arbeiten. Das Programm (Delphi) hat ein Hauptprogramm und sehr viele Plugins in Form von weiteren exe-Dateien, welche aber über das Hauptprogramm geladen werden.

Meine Frage ist nun: Erstelle ich nur ein Git-Projekt, welche die Quelltexte aller Programme/Plugins beinhaltet oder erstelle ich ein Projekt für die Hauptanwendung und für jedes Plugin ein weiteres Projekt?

Letztere Variante wäre für die Zugriffsberechtigungen einzelner Projektteilnehmer vllt. besser. Und wenn man neuze Zweige erstellt, muss nicht immer das gesamte Projekt ausgecheckt werden, wenn man eigentlich nur an dem Plugin XY arbeitet.

Wie handhabt ihr das so?

Danke im Voraus!

[Sherlock]

Du musst doch gar nichts auschecken und Speicherplatz gibts quasi geschenkt. Das mit den Zugriffsrechten ist natürlich eine andere Sache, dazu kann ich leider nichts sagen.

Sherlock

[Dejan Vu]

Zitat von Sherlock:

Du musst doch gar nichts auschecken..

Wie kommst Du denn sonst an die Änderungen von deinen Kollegen?

[Bernhard Geyer]

Zitat von DJ-SPM:

Letztere Variante wäre für die Zugriffsberechtigungen einzelner Projektteilnehmer vllt. besser.

Es ist so schlimm wenn einzelne Projektteilnehmer auch andere Plug-ins sehen und dann vorhanden Code wiederverwenden/basisklassen, Units ableiten?
Gibt es Sicherheitsgründe das einzelne Teilnehmer nicht alles sehen dürfen?

[Sherlock]

Zitat von Dejan Vu:

Zitat von Sherlock:

Du musst doch gar nichts auschecken..

Wie kommst Du denn sonst an die Änderungen von deinen Kollegen?

Bei git? Durch "pull" - ist freilich nur ein anderes Wort. Aber auschecken hat einen Beigeschmack, der der VCS Historie geschuldet ist: Früher war auschecken blockierend, d.h. Änderungen an ausgecheckten Dateien waren nur dem "Auschecker" vorbehalten. Wir haben uns angewöhnt, die alten Begriffe zu vermeiden, weil sie eben entsprechend alte Vorstellungen mit sich bringen.

Sherlock

[TheMiller]

Ja, das hast du Recht.

Ich meinte auch eher, dass die Übersicht, Namensgebung der Zweige etc. darunter leidet, wenn alle Projektteile in einem Projekt zusammengefasst sind. Ich weiß nicht, welche Vor- und Nachteile so ein "Komplettpaket" mit sich bringt - daher frage ich lieber nach.

Derzeit tendiere ich dazu, für jedes Plugin ein eigenes Projekt im Namensformat "Programmname - Plugin - Plattform" zu erstellen. So kann man schön Rechte vergeben, Zweige erstellen ohne das die Gesamtübersicht darunter leidet etc.

Was haltet ihr davon?

[Valle]

Wir haben auf Arbeit mehrere Git-Repositories für ein großes Projekt angelegt. Es handelt sich um ein CMS, ein CRM und weitere webbasierter Serversoftware. Alles greift auf eine "lib" zu, die ziemlich groß und mächtig ist. ALles was irgendwelche Gemeinsamkeiten aufweist, ist in der lib, alles andere in den einzelnen Repositories.

Ich kann diesen Ansatz leider nicht empfehlen, da sich bei uns die lib immer weiter ausdehnt und mittlerweile Dinge enthält, die da eigentlich gar nicht mehr wirklich reingehören. Beispielsweise Routendefinitionen (also Pfadangaben in URLs) für das Ausloggen, da dieser Link auf allen Webservices verfügbar sein muss. Auch ist die Auftrennung teilweise unsauber, da manche Teile sowohl in der lib als auch in den einzelnen Projekten zu finden sind. Auch die Versionierung ist sehr aufwendig geworden, da man für lib-Änderungen gleich mehrere neue Versionen in anderen Projekten einführen muss. (Es handelt sich um Git Submodules)

Ob das jetzt vergleichbar ist kann ich dir nicht sagen. Just my 2 cents. Vielleicht hilft's!

[Elvis]

Kommt die Anwendung ohne die Plugins klar?
Wenn ja, dann alles in ein eigenes Repository.

Die Plugin API (zum Beispiel ein Header file, COM-Lib, Delphi interfaces etc) sollte vllt auch ein eigenes Repo sein, selbst wenn es momentan nur eine Datei sein sollte.

In allen Repos, die Zugriff auf die Plugin API brauchen kannst du die dann als sub module hinzufügen.

Für den fertigen Build kannst du dir ein Container Repo machen, welches alle Repos als submodules hat, welche für den jeweiligen Build interessant sind.
Alle Projekte sollten mit relativen Pfaden zueinander klar kommen, sonst brauchst du das gar nicht erst versuchen.

Bei Submodules merkt sich Git auf welches Changeset du zeigst (kommt mit ins Commit). Dadurch kriegst du immer den passenden Stand in den submodules wenn du eine ältere Version haben willst.

Das ist jetzt nix neues, das ging schon vor Git.
Das ist auch nicht super toll. Es ist aber halt besser als alle & ihren Opa zusammenzuwerfen.

Es kann sich als sinnvoll erweisen, einige der Plugins zusammen mit dem Hauptprogramm zu versionieren, da es ohne sie nicht auskommt und vllt auch von den gleichen Leuten gepflegt wird.
Aber das könnt nur ihr selbst entscheiden.

Zu den Berechtigungen:
Passt auf, dass ihr keine Rechte-Nazis werdet.

Sorgt dafür, dass alle im Team wenigstens den Code sehen und einen Fork/Pullrequest anlegen können. Sie sollten auch überall Changesets bewerten/kommentieren können.
Denn wenn Heinz einen Fehler sieht, sollte er ihn auch ohne Krämpfe anzeigen können. Oder vllt. sogar schnell einen Pullrequest von einem Fork mit dem Fix anlegen können.
Das heißt, Heinz kann ein Problem lösen, ohne direkt auf das Development Repo schreiben zu können.