Versionskontrollsystem einrichten (GIT) - Ideen

[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 von himitsu:

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.