Versionskontrollsystem einrichten (GIT) - Ideen

[Der schöne Günther]

Zitat von haentschman:

Moin...

Zitat:

ob ich wieder ein großes Repository mache

...schlechte Idee.
Begründung:
Alle Commits ALLER Projekte in einem "Graph" ist unübersichtlich.

Jetzt könnte man sich aber fragen, weshalb Microsoft, Facebook, Google das alle so machen.

https://monorepo.tools/#what-is-a-monorepo


Ich bin aber ganz ehrlich, wir haben uns mit so etwas auch nicht anfreunden können. Fahren weiterhin den klassischen Pfad, dass eine interne Library (dein Ordner "CommonUnits") ein eigenes Repo ist.

[haentschman]

Zitat:

weshalb Microsoft, Facebook, Google das alle so machen

...Submodule hinter Submodule. Imho. Wer kann sich den "Verwaltungsaufwand" leisten? ...neben der Programmierung.

[himitsu]

nja, gehen würde es,

z.B.

• das Hauptverzeichnis und die Struktur als Repo, mit SubModules
• die ganzen UnitGroup* als eigene Repo
• die ganzen Programm* als eigene Repo
• die vielen common als eigene Repo oder vielleicht auch direkt im Haupt-\ÜberRepo

• vielleicht auch alle CommonUnits und Projectgroup* bzw. ProjectgroupUniversal in einem Zwischen-Repo, als Struktur

• oder CommonUnits als ganzes SubModul, mit allen UnitGroup* (diese nicht mehr einzeln)

• oder nur die einzelnen Unterverzeichnissse / Teil-Repos und die Verzeichnisstruktur darüber manuell)
• oder gar die Grundstruktur bissl neu aufteilen / umorganisieren
  also mit oder ohne einem Master-Reop und die einzlnen Teilrepos in einer flacheren Struktur alle nebeneinander
• ...

Man kann sogar wirklich alles in ein Repo und das dennoch getrennt machen, wenn man masochistisch genug veranlagt ist.

• also wie oben auftrennen, aber nicht als mehrere Repos, sondern als "eigentständige" Branches nebeneinander in ein/mehrere Repo
  git checkout --orphan BRANCHNAME
• dann sind alle History voneinander getennt
• und das dann aber als unabhängige Work-Tree in den oben erwähnten Strukturen vom selben .git-Verzeichnis auschecken

Ach ja, es gibt zumindestens viele Anleitungen/Converter/Tools, welche die HG-Historie nach GIT importieren können,
damit du die alte Geschichte beim Umzug nicht verlierst.
Vermutlich geht es ähnlich wie von SVN aus, wo man auch einzelne Verzeichnisse und nur jeweils ihre Historie übernehmen kann,
mit oder ohne alte Branches. (bei SVN waren Branches ja meistens danebenliegende Unterverzeichnisse)