Versionskontrollsystem einrichten (GIT) - Ideen

[bernau]

Ich habe Mercurial mit TortoiseHG als Versionskontrollsystem eine Zeit lang lokal verwendet. Irgendwie ist die Nutzung aber eingeschlafen. Fragt mich nicht warum. Ist so passiert. Egal.

Über verschiedene andere Projekte bin ich mit Github/GitLab und somit mit GIT allgemein in Berührung gekommen. Ich habe mir nun zum Test im lokalen Netz einen GitLab-Server eingerichtet und mit "Spielverzeichnisen" den Workflow (Commit,Push,Pull, etc.) getestet. Ich bin ganz zufrieden damit und bin jetzt soweit, dass ich richtig damit starten kann.

Bisher (also damals war der ganze Code nur Lokal auf meinem Rechner. Alles ist in ein großes Repository (DelphiDir) gekommen. Für die verschiedenen Projekte und Tools habe ich dann Labels verwendet um die Commits einigermaßen auseinander zu halten. Jetzt wo ich neu Anfange, möchte ich mir mal ein paar Ideen geben lassen, wie ich das ganze besser organisieren kann.

Meine Verzeichnisstruktur sieht vereinfacht ungefähr so aus:

Code:

DelphiDir ---- CommonUnits ----- UnitGroup1
           |                 |-- UnitGroup2
           |                 |-- UnitGroup3
           |
           |-- Projects -----ProjectgroupA-----ProgrammA1
                          |                 |--ProgrammA2
                          |                 |--ProgrammA3
                          |                 |--common
                          |
                          |--ProjectgroupB-----ProgrammB1
                          |                 |--ProgrammB2
                          |                 |--ProgrammB3
                          |                 |--common
                          |
                          |
                          |--ProjectgroupUniversal-----ProgrammUniversal1
                                                    |--ProgrammUniversal2
                                                    |--ProgrammUniversal3

Alle Programme im Verzeichnis Projects verwenden Units aus CommonUnits
Programme aus ProjectgroupA und ProjectgroupB verwenden auch Units\Forms aus ProjectgroupUniversal
Programme aus ProjectgroupA verwenden units aus ProjectgroupA\common
Programme aus ProjectgroupB verwenden units aus ProjectgroupB\common

Wie gesagt, ich überlege mir jetzt ob ich wieder ein großes Repository mache, oder ob ich mehrere projektbezogene Repositories anlege. Wie ist euer Workflow?

[himitsu]

Wenn die CommonUnits im SearchPath des Compilers liegen
und vielleicht sogar vorkompiliert,
dann ist es doch egal, wo sie liegen


Natürlich könnte man die Struktur auch so belassen und Teile/Verzeichnisse davon einzlen in eigene Repository,
notfalls auch noch mit einem/mehreren Master-Repository und dann darin mehrere SubModules (eingebettete Unter-Repository)
und das auch notfalls auch mehrfach verschachtelt.
(falls Einiges immer an einem bestimmten Ort liegen muß)

[haentschman]

Moin...

Zitat:

Wie gesagt, ich überlege mir jetzt ob ich wieder ein großes Repository mache

...schlechte Idee.
Begründung:
Alle Commits ALLER Projekte in einem "Graph" ist unübersichtlich. Ich hab immer "develop" und "release" Zweige pro Projekt. (Bilder) Stelle dir vor, daß noch Commits dazwischen liegen. Was gehört wozu? "Master" wäre bei einem großen Repro für alle da...

Zitat:

war der ganze Code nur Lokal auf meinem Rechner...
Ich habe mir nun zum Test im lokalen Netz einen GitLab-Server eingerichtet...

...noch schlechtere Idee. Besser Außer Haus...Bitbucket, GitHub etc. Lokal nur mit entsprechender Backup Strategie.

PS:
Auch ein Ticketsystem ist brauchbar. Statt Labels hast du dann Ticketnummern und eine Historie der "Aufgabe" (Bild2)
https://mantisbt.org/ ...Freeware (Bild3)

PS:

Zitat:

Irgendwie ist die Nutzung aber eingeschlafen.

Ich könnte mir nicht mehr vorstellen ohne ein Versionskontrollsystem zu arbeiten. Ständig springen zwischen Zweigen, zurücksetzen, vergleichen...und das ohne? Nö.

[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)

[bernau]

Zitat von haentschman:

Zitat:

Wie gesagt, ich überlege mir jetzt ob ich wieder ein großes Repository mache

...schlechte Idee.
Begründung:
Alle Commits ALLER Projekte in einem "Graph" ist unübersichtlich. Ich hab immer "develop" und "release" Zweige pro Projekt. (Bilder) Stelle dir vor, daß noch Commits dazwischen liegen. Was gehört wozu? "Master" wäre bei einem großen Repro für alle da...

Das unübersichtliche hat mich auch gestört. Deshalb die Idee, statt einem großen Repository ein kleines zu machen.

Der Vorteil am großen Repository war aber, dass ich immer sofort gesehen habe, was ich an einem bestimmten Tag unabhängig vom Projekt gemacht habe.

Zitat von haentschman:

Zitat:

war der ganze Code nur Lokal auf meinem Rechner...
Ich habe mir nun zum Test im lokalen Netz einen GitLab-Server eingerichtet...

...noch schlechtere Idee. Besser Außer Haus...Bitbucket, GitHub etc. Lokal nur mit entsprechender Backup Strategie.

Die Backupstrategie "außer Haus" ist da. Die Musst du aber auch bei einem Service außer Haus haben. Will nicht den Teufel an die Wand malen, aber auch bei Amazon und Co. sind Daten verloren gegangen.

Zitat von haentschman:

Zitat:

Irgendwie ist die Nutzung aber eingeschlafen.

Ich könnte mir nicht mehr vorstellen ohne ein Versionskontrollsystem zu arbeiten. Ständig springen zwischen Zweigen, zurücksetzen, vergleichen...und das ohne? Nö.

Deshalb will ich ja wieder ein Versionskontrollsystem einführen.

Bei mir ist die Nutzung eingeschlafen, weil ich meine Verzeichnisstruktur und Unitnamen über die letzten fünf Jahre reorganisiert habe. Ich habe seit 30 Jahren meine 10 festen Projekte. Wer kennt nicht die Sauereien, die man in 30 Jahren so gemacht hat. Das war alles so gewachsen, dass es extrem gestört hat. Früher habe ich innerhalb eines Projektes viele Unterverzeichnisse für die jeweiligen Programmteile gehabt. Also z.B. Benutzer, Kunden, Statistik, Serienbrief, Lager und viel mehr. Da gab es pro Projekt teilweise 50-80 Unterverzeichnisse. Dann habe ich irgenwann Namespaces für die Units eingeführt und alle Units mit der Zeit in "ein" Projektverzeichnis verschoben. Das ist für mich viel eleganter und lesbarer.

Das alles hatte aber den Nachteil, das Hg ins schleudern gekommen ist. Dateien umbenennen UND Verschieben mochte es nicht so. (Kann auch sein, dass ich falsch bedient haben) deshalb habe ich irgenwann das ganze Repository entfernt, weil es mehr gestört hat, als genutzt.

[himitsu]

Backup: Ich lass mir einfach automatisiert einen Clone vom Github auf mein NAS ziehen.

Zitat von bernau:

Der Vorteil am großen Repository war aber, dass ich immer sofort gesehen habe, was ich an einem bestimmten Tag unabhängig vom Projekt gemacht habe.

OK, du könntest z.B. im GitHub auch global über alle Repos dir auflisten lassen was wo los war.

Genauso kann man auch mehrere unabhängige "Branches" (Projekte) in einem Repo haben,

oder auch mehrere Repos als Remote-Quellen in "ein" lokales Repo Verzeichnis auschecken clonen.
Hier habe ich z.B. einen Fork im GitHub und als zweite Source im lokalen Repo noch das Original mit drin.
git remote add original [e-mail]:xxxx/yyyyy.git (OK, "original" ist vielleicht nicht der beste Name, als unverwechselbaren Vergleich zum "origin")

Dann hast du lokal in deinem Git-Log auch die Historie gemeinsam ("alle" Branches anzeigen, anstatt nur das Aktuelle)



https://github.com/geheimniswelten/DECMath-Legacy
der "Original"-Branch ist so ein unabhängiger "Orphan", dessen Historie nicht von einem gemeinsamen Parent ausgeht.

[himitsu]

PS: Wer z.B. von SVN/HG zu Git migriert, kann natürlich auch so einen Mist bauen, wie Emba.
Je Delphi-Version ein neues Repo, anstatt das als Commit/Branch/Tag/sonstwas in einem Repo zu verwalten.
https://github.com/Embarcadero/RADStudio12Demos

Mit dem geilen "Vorteil", dass man nicht sieht, was der Unterschied zur Vorgängerversion ist,
aber auch nicht den alten Mist mit ins neue Delphi mitschleppt.

[bernau]

Danke himitsu,

sehr interessante Gedankengänge.