Ich würde dir noch einen Git server empfehlen, z.b. Gitlab oder Gitea. Wenn du ja eh ein NAS hast, einige NAS können VMs oder sogar Docker laufen lassen, da könntest du das dann drauf hosten.
Abgesehen davon, mal zu deinen einzelnen punkten:
1. "Git" auf beiden Linux-Maschinen (zur Zeit "Debian KDE" und "Mint Cinnamon 19.3") und "Windows 10 Home" installieren..
Dafür sollte man eigentlich nicht wirklich ne anleitung brauchen, ist ganz einfach: Windows: Exe runterladen und installieren, Linux: Über paketmanager deiner Distro installieren.
Konfigurieren muss man git eigentlich gar nicht (abgesehen von name und e-mail, das sagt einem git aber auch wenn man commiten möchte nochmal wie das geht).
2. Die "Git-Gui" überall einrichten.
Also ich finde die git gui grässlich. Gibt ein paar GUI tools für git die brauchbar sind, grundsätzlich kann ich aber nur empfehlen mit git in der konsole warm zu werden. Vor allem wenn du erfahrener mit git wirst kannst du aliase (makros) für git definieren mit denen du dann viele arbeitsabläufe automatisieren kannst, was du in einem GUI schlicht weg nicht hast (ich hab z.b. das makro git fork-master, was änderungen stasht, master auscheckt, pullt, und in einen neuen branch forkt. In einer GUI wären das 4 schritte statt einem).
3. Dafür sorgen, das Git seinen Sachen auch auf dem NAS speichert.
Ich kann dir wirklich nur sowas wie Gitlab empfehlen, das kannst du privat auf einem rechner hosten, das bietet nicht nur die git standard features, sondern noch ne ganze menge anderer features, z.B. CI/CD womit du automatisch bei jedem push die sourcen compilen kannst um z.b. Compilierfehler zu entdecken, oder einen Release zu bauen den du dann einfach runterladen kannst.
Ich kann z.b. einfach bei einem meiner projekte eine zeile ändern, pushen und es wird vollautomatisch für Windows und Linux gebaut und ich kann mir den release einfach via der gitlab wesite runterladen.
4. Git mit Lazarus verbinden.
Ich weiß nicht wirklich ob das geht, ich hab einfach immer ne konsole im aktuellen projekt ordner offen (hab ich sowiso, selbst ohne git)
- Wenn ich mittels Laz für verschiedene OS kompilieren will, wie separiert man die einzelnen Zweige in Git oder braucht man das nicht?
-- Grundsatzfrage: Wie baut man das Projektverzeichnis in diesem Fall am besten auf und wie passt man die Build-Mode am besten an?
Du brauchst keine eigenen branches für die verschiedenen cross builds, {$ifdef LINUX} oder {$ifdef Windows} im code sollte vollkommen ausreichend sein.
Build modes brauchst du wenn du cross compilen willst, da stellst du für jedes target einfach einen build mode ein. Außerdem würde ich noch einen Debug-Build mode haben, der plattform unabbhängig ist
- Ist es sinnvoll, Git vor jedem Kompilieren laufen zu lassen, damit man bei einem Crash, an den Stand vorher herankommt.
Je nachdem wie du arbeiten willst. Willst du git als dokumentationstool haben, dann mach lieber eher große "vollständige" commits, i.e. ein commit für ein komplettes (sub)feature, und schreib in die commit message dann auch was rein was hilfreich ist. Ich schreib meist eine headline die alles zusammenfasst sowie 1-3 paragraphen die dann erklären was genau gemacht wurde.
Wenn du git nur für das VCS willst und dich commit messages nicht interressieren (sieht man öfters, so git logs in denen jeder commit eine message mit weniger als 10 wörtern hat), dann lohnt es sich einfach in regelmäßigen abständen (z.b. alle stunde, alle 100 lines oder so) zu committen damit du genau zurückblicken kannst was du wann gemacht hast.
Ich empfehle persönlich eher die erste rangehensweise, da wenn du nach nem jahr oder so mal dir eine bestimmte feature implementierung/änderung ansehen willst, findest du sie beim zweiten ansatz schlicht weg nicht. Ohne vernünftige commit messages und commit strukturen (z.b. 5 commits die eigentlich zusammen gehören verstreut über 20 andere commits), hast du einfach keine chance raus zu finden welcher stand jetzt genau der war den du suchst. (oftmals hat man dann auch das problem das ein commit noch nicht fertig war, der nächste aber schon ein anderes feature angefangen hat).
- Wie stellt man sicher, das die drei OS immer an der gleichen Version arbeiten (aktuell nicht zeitgleich)?
Wenn nicht zeitgleich, dann ganz einfach: bevor du was machst pullen, nachdem du fertig bist commiten und pushen.
Wenn zeitgleich, dann für jedes feature einen eigenen branch bauen, und dann wenn der branch fertig ist in master mergen. Somit bleibt die arbeits version stabil (die version vom zeitpunkt des branches) bzw. kann nach einem merge auf master auch auf den anderen branches geupdated werden.
Was du nicht willst ist zeitgleich auf dem selben branch arbeiten, besonders wenn rebases gemacht werden, denn dann kannst du ganz schnell sachen kaputt machen.
Verein
Links
Suche