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...8-)

Zitat:

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

...schlechte Idee. :warn:
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. :zwinker: 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" :wink: (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ö. :zwinker:

:wink:

[Der schöne Günther]

Zitat:

Zitat von haentschman (Beitrag 1534474)

Moin...8-)

Zitat:

ob ich wieder ein großes Repository mache

...schlechte Idee. :warn:
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. :gruebel: Wer kann sich den "Verwaltungsaufwand" leisten? ...neben der Programmierung. :zwinker:

[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
  
  Delphi-Quellcode:

  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:

Zitat von haentschman (Beitrag 1534474)

Zitat:

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

...schlechte Idee. :warn:
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:

Zitat von haentschman (Beitrag 1534474)

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. :zwinker: 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:

Zitat von haentschman (Beitrag 1534474)

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ö. :zwinker:

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:

Zitat von bernau (Beitrag 1534491)

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.

Delphi-Quellcode:

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, :wall:
aber auch nicht den alten Mist mit ins neue Delphi mitschleppt.

[bernau]

Danke himitsu,

sehr interessante Gedankengänge.

[freimatz]

Zitat:

Zitat von bernau (Beitrag 1534491)

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.

Da kommt git nach meiner Erfahrung gut damit zurecht. Nur allzuviel noch zusätzlich ändern macht Probleme. (Den unit Namen muss man ja meist anpassen.)

[himitsu]

Jupp, verschieben und änderungen sollte man in getrennten Commits ablegen.

GIT will das unbedingt automatisch machen.
SVN hat sich genau gemerkt welche Datei zu welcher kopiert/verschoben wurde,
aber GIT speichert das nicht und verlinkt es zur Laufzeit, also macht "life" aus einem Delete und Add ein "Move", was dann aber nicht immer der Wirklichkeit entsprechen muß, wenn die Heuristik es nicht hinbekommt Quelle und Ziel richtig zusammenzubekommen.
Sei es weil mehrere gleiche/ähnliche Dateien verschoben wurden, oder weil gleichzeitig noch Änderungen in den Dateien enthalten sind. Sowie bei "zu viel auf einmal" schaltet sich die Heuristik auch ab.

[jaenicke]

Ich finde es schwierig, wenn man gemeinsame Units nicht im gleichen Repository hat. Denn auch die passt man ja mal an. Wenn man dann einen bestimmten Stand herstellen möchte, muss man erst genau schauen, dass man den richtigen Stand in beiden Repositorys auswählt. Und wenn man eine größere Änderung macht, die in einen separaten Branch gehört, bis sie fertig ist, muss man diesen Branch ggf. in zwei Repositorys pflegen.

Ich verstehe natürlich auch die andere Seite und man kann natürlich auch mit Submodules viel machen, aber persönlich gefälllt mir ein großes Repository mit einem definierten Stand für alle beteiligten Units am besten.

Zitat:

Zitat von freimatz (Beitrag 1534521)

Da kommt git nach meiner Erfahrung gut damit zurecht. Nur allzuviel noch zusätzlich ändern macht Probleme. (Den unit Namen muss man ja meist anpassen.)

Darum habe ich mir angewöhnt zuerst zu verschieben und den Dateinamen anzupassen (ggf. in getrennten Commits) und dann den Unitnamen in der Datei anzupassen... (indem ich beim Einchecken die Änderung zurückgenommen und nach dem Commit wieder gespeichert habe)
Das ist zwar etwas mehr Aufwand, aber dafür ist die History sauberer.

[himitsu]

Nunja, man muß die Repository halt entsprechend versionieren (z.B. als Branches oder Tags), und das bei "problematischen" Änderungen auch immer aktuell halten
dann kann jedes Programm angeben, welche Version genommen werden soll,

aber dann kann es nicht über ein gemeinsames Verzeichnis gehen,
sondern jeder muß seine eigene Kopie (clone) besitzen, wo dann die passende Version ausgecheckt werden kann.

Bei GIT-SubModulen ist eh immer nur der RepoName angegeben (.gitmodules) die CommitID gespeichert (ID des SubModules, als Eigenschaft am Verzeichnis, wo es eingebunden ist wird im Commit gespeichert)
Schade, dass man nicht auch sagen kann "nimm das Aktuelle dieses Branches", bzw. "nimm diesen TAG, wo auch immer er grade steht". (gefühlt war das im SVN besser geregelt)
Allerdings wird das nur beim Clonen (ersten runterladen) beachtet. Ändert sich die gespeicherte CommitID im Repo, dann wird es beim Checkout nicht angepasst, sowie auch wenn man anschließend selbst im SubModul den Branch ändert, bzw. anderen Commit auscheckt, dann stimmt es nicht mit der "Vorgabe" überein ... zumindest wird aber im DIFF angezeigt, dass die CommitID dieses "Verzeichnisses" nicht übereinstimmt.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1534552)

Allerdings wird das nur beim Clonen (ersten runterladen) beachtet.

Ich bin mir nicht sicher, ob wir dasselbe meinen, aber bei Fork gibt es eine Einstellung Update submodules automatically on checkout. Damit werden die Submodules beim Wechsel eines Branches oder einer Revision auf den passenden Stand nachgezogen.

[jaenicke]

Das macht bei einem größeren Team schon Sinn, aber wenn nur wenige Entwickler das nutzen, finde ich es viel einfacher, wenn man ein Repository hat, wo dann ein Branch auch direkt die gemeinsamen Units umfasst.

Das ist aber auch ein Thema, bei dem es viele verschiedene Meinungen, Gewohnheiten und Vorlieben gibt. Insofern muss man da seinen eigenen Weg finden.