Versionskontrollsystem einrichten (GIT) - Ideen

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