Kleines GIT-Verständnisproblem zwischen zwei Rechnern

[alfware17]

Hallo ich habe vor, einen Teil meiner Java-Sourcen mal dem GitHub anzuvertrauen. Bisher habe ich immer, wenn ich zwischen 2 PC was austauschen wollte, den kompletten Workspace rüber kopiert, das ist bei mir unproblematisch, da deutlich < 1GB. Ich habe auf den PC auch immer die gleiche Eclipse-Version, bisher Oxygen mit JDK8/32 und ab jetzt neu 2022-09 mit dem eingebauten JDK17.

Es ist mir schon gelungen, an dem einen PC mein Repository auf einen Unterordner des Workspaces zu legen und dort zwei kleine Projekte zu erstellen (eigentlich copy+paste) - mehrfach ändern, Commit und voila. Gitahead sieht die neuen Projekte (ich könnte auch online gucken).

Nun der für mich kitzligere Teil. Wie muß der neue PC/Eclipse anfangen - mit einem Workspace gleich mit dem Ordner, auf dem das Git synchronisiert ist (würde eben Stand jetzt eine 1:1 Kopie machen)? Was wenn Eclipse gleich einen Workspace-Build macht, dann ist das doch nicht mehr gleich und die Synchronisierung läuft ungewollt an?

Oder muß ich einen Workspace nehmen OHNE diesen Ordner und dann neu klonen. Kann ich mir nicht vorstellen, weil doch was Arbeit? Kann man nicht einfach den Workspace so 1:1 nehmen? Was kann da schief gehen. Ich habe extra keine wichtigen Projekte drauf, will nur probieren.

Und, wenn ich keinen aktuellen Workspace nehme zum Kopieren, sondern sage mal 1 Woche alt. Auf dem ersten PC kann zwischendurch gearbeitet worden sein, Projekte geändert, hinzugekommen oder gelöscht. Wenn ich nun direkt Eclipse aufrufe, ist das Verzeichnis noch mit dem Repository verbunden? Neu klonen kann ich sicher nicht,
aber was wenn die lokalen Änderungen (committed oder nicht), auseinander laufen? Fragen über Fragen...
Und nein, ich will das nicht "professionell" machen, meine Zeit der Software-Entwicklung und Versionierung im Betrieb ist etwas zurück, ich mache das jetzt nur privat aus Spaß an der Freude...

 

[Robert Zenz]

Oder muß ich einen Workspace nehmen OHNE diesen Ordner und dann neu klonen.

Korrekt, ist die einfachste Vorgehensweise.

Auf dem ersten PC kann zwischendurch gearbeitet worden sein, Projekte geändert, hinzugekommen oder gelöscht. Wenn ich nun direkt Eclipse aufrufe, ist das Verzeichnis noch mit dem Repository verbunden?

Moment, idealerweise hast du fur jedes Projekt ein eigenes Repository. Wenn das aber nicht so passend ist, dann hast du die Projekte ohne Eclipse Workspace im git. Wenn dan Projekte weggehen oder hinzukommen, musst du das eben entsprechend auf dem anderen PC anpassen. Den gesamten Eclipse Workspace im Git zu haben ist (wie ich aus eigener Erfahrung weisz) nicht so ganz anzuraten weil grosz und kompliziert.

Neu klonen kann ich sicher nicht,
aber was wenn die lokalen Änderungen (committed oder nicht), auseinander laufen?

git merge beziehungsweise wirft Git dann einen "merge conflict" und dann musst du dich eben entscheiden ob du entweder deine Aenderungen, die Aenderungen der anderen Seite, oder beide kombiniert behalten willst.

Es ist mir schon gelungen, an dem einen PC mein Repository auf einen Unterordner des Workspaces zu legen und dort zwei kleine Projekte zu erstellen (eigentlich copy+paste) - mehrfach ändern, Commit und voila.

Am einfachsten ist es, meiner Meinung nach, wenn du die Projekte auszerhalb des Workspaces hast. Dann hast du aus auch digital davon abgekoppelt. Diese werden dann nur in den Workspace importiert, also nur dort angezeigt. Also zum Beispiel dein Workspace liegt unter /home/alfware17/.config/eclipse/workspace und deine Projekte unter /home/alfware17/src/. Wenn Projekte sich aendern oder hinzukommen, musst du dann eben entsprechend diese aus dem Workspace werfen oder importieren.

Hallo ich habe vor, einen Teil meiner Java-Sourcen mal dem GitHub anzuvertrauen.

Bitte beachte zum einen dass der Quellcode eine Lizenz haben sollte wenn er veroeffentlicht wird (ansonsten ist er "All Rights Reserved", oder auch bekannt als "andere koennen gar nichts damit machen") und das GitHub noch eigene Bedingungen aufschlaegt (zum Beispiel dass sie damit ihre LLM Loesungen befeuern).

 

[alfware17]

Mein Repository dafür ist privat gestellt und ich wollte eigentlich auch keine wichtigen Sachen da speichern. Ich will die Git-Funktion nur mal ausprobieren und wie es wäre mit verschiedenen Rechnern (oder Personen) an so was zu arbeiten. Das hatte mich damals so vor ca. 7 Jahren so fasziniert, allerdings traue ich dem Git auch nicht so weit von der Robustheit und so. Wenn ich was weitergeben/veröffentlichen wollte, ist es vielleicht ok aber dann nehme ich sogar ein anderes Konto.

 

[Robert Zenz]

allerdings traue ich dem Git auch nicht so weit von der Robustheit und so.

Versteh' mich jetzt nicht falsch, aber damit wird der Linux-Kernel entwickelt. Ich will jetzt nicht behaupten dass Git nicht auch Probleme oder Fehler hat, aber "Robustheit" kann man dem Ding zumindest nicht absprechen.

Ich will die Git-Funktion nur mal ausprobieren und wie es wäre mit verschiedenen Rechnern (oder Personen) an so was zu arbeiten.

Fuer gewoehnlich teilt man die Eclipse Workspaces in dem Fall nicht. Die IDE-Projekt-Dateien (.project und so weiter) eventuell noch, aber gibt genug die sogar davor die Nase ruempfen (zu Unrecht die meiste Zeit). Also idealerweise, wie ich bereits sagte, hast du die Porjkete in einem Repository, den Workspace nicht, und importierst dann immer die Projekte in den Workspace auf dem Rechner wo du gerade bist. Die Eclipse-Projektdateien wuerde ich da jetzt mit einchecken, weil dann hast du die projektspezifischen Einstellungen auch immer alle dabei.

 

[alfware17]

Ich glaube wir meinen beide etwas Ähnliches. Mit "Robustheit" meinte ich daß ich mir nicht vorstellen kann, daß nun auch bei Zusammenarbeit von mehreren Personen immer gleich alles und jede Änderung des Projektverzeichnisses eingecheckt werden muß und daß Git bei so ein paar Hundert, Tausend und mehr Dateien und Kopieroperationen sich auch mal verhaspelt. Das würde ich doch lieber auf dem Heim-PC haben und so wie du sagst, den Workspace aus dem privaten Projekteverzeichnis aktualisieren. Das Ergebnis dann in den entsprechenden Versionen ins Internet.
Es gibt auch lokal bzw im Netzwerk schicke Versionierungs- und Einchecksysteme, Tortoise damals bei uns, ich weiß gar nicht ob es die noch gibt,

Aber, mein Java-Fundus ist begrenzt - ich habe nur so ca 100 Projektchen, die habe ich halt alle im Workspace und den verteile ich zwischen meinen PC als Ganzes, das ist dann eben Java. Andere Programmiersprachen sind wieder woanders. Die haben uns nur damals in so einem Anfängerkurs auch gezeigt, daß Eclipse auch einen eigenen Git-Assistenten hat und da wollte ich ihn ausprobieren. Habe 2 Projekte von mir per copy+paste auf einen extra Ordner gesetzt und den dann mit dem Git verbunden. Nun will ich sehen, was ein anderer PC mit dem Ordner/Git so anfängt und ob es da nicht Synchronisierungsprobleme gibt, wenn die Workspace-Space Kopie dann was älter wird.
Wie du sagst, neu klonen oder wenigstens PULL wird wohl schlau sein.

 

[KonradN]

daß Git bei so ein paar Hundert, Tausend und mehr Dateien und Kopieroperationen sich auch mal verhaspelt.

Wieso sollte sich Git da "verhaspeln". Es wird ja für jede Datei der gleiche Algorithmus aufgerufen. Verhaspelt sich Dein Code, wenn Du diesen 100 oder 1000 Mal hintereinander aufrufst? Git ist robust, es gibt manchmal zwar User, die da irgendwas meinen, aber das stellt sich - so wie ich das sehe - immer darauf hinaus, dass User schlicht zu blöd waren und halt falsch gemerged haben. Und ja - da kann man als User halt Anpassungen auch wieder rauswerfen...

Und die Tatsache, das so viel auf Git gesetzt wird: Das wäre wohl kaum der Fall, wenn es da irgendwelche Probleme gäbe.

bei Zusammenarbeit von mehreren Personen immer gleich alles und jede Änderung des Projektverzeichnisses eingecheckt werden muß

Also ich empfinde es als positiv, Änderungen immer zeitnah einzuchecken. Alleine schon, um eine Art Backup zu haben. Daten gehen so schnell verloren - nicht nur durch Defekt oder Diebstahl sondern auch durch Aktionen des Users. Gerade bei größeren Refactorings ist es super, da einen festen Stand zu haben, mit dem man dann vergleichen oder auch ganz zurück wechseln kann. Aber das dann in der Regel in eigenen Branches, so dass Entwickler ungestört voneinander arbeiten können. Zur Arbeitsweise mit Git hatten wir vor kurzem aber auch erst einen Thread, der evtl. interessant sein könnte:

https://www.java-forum.org/thema/git-best-practice.204703/

Ansonsten empfehle ich auch die Bücher zu Git, die frei verfügbar sind:

Git

git-scm.com

Das deutsche Git-Buch

gitbu.ch

 

[Barista]

Es gibt auch lokal bzw im Netzwerk schicke Versionierungs- und Einchecksysteme, Tortoise damals bei uns, ich weiß gar nicht ob es die noch gibt

Tortoise ist jeweils nur die GUI für das jeweilige Versionierungssystem.

Das gibt es noch:

TortoiseGit – Windows Shell Interface to Git

tortoisegit.org