Hier entsteht eine Anleitung, wie man an die Dateien aus dem Git-Repository (https://github.com/dead-flunky/PieAncientEurope) kommt, wie man dazu beitragen kann und was sonst noch so an Fragen auftaucht.
Die Anleitung wird sich im Laufe der Zeit weiterentwickeln und/oder auf externe Quellen verweisen.
GitHub bietet im wesentlichen einen Server für Git-Repositories, also versionierte Code-Datenbanken. Die Erstellung von öffentlich einsehbaren Repositories (open source) ist kostenfrei.
Um eigenen Code beitragen zu können, wird ein Account benötigt.
Die Authentifizierung in Drittanbieter-Apps (s.u. TortoiseGit) via Passwort funktioniert aus Sicherheitsgründen nicht mehr. Am einfachsten ist die Nutzung eines SSH-Keys (s.d.).
Um einen SSH-Key einzubinden geht man oben rechts im Browserfenster auf das Benutzericon --> Settings
Dort den Reiter "SSH und GPG keys" auswählen und über den Button "New SSH key" einen extern erzeugten SSH-Key einfügen. Im Bild seht ihr meinen öffentlichen Schlüssel, das private Gegenstück liegt verschlüsselt auf meinem PC.
Anschließend könnt ihr im Repository neben HTTPS und GitHub CLI auch SSH als Methode zum Clonen der Dateien auswählen.
Geändert von Flunky (22. Oktober 2021 um 15:24 Uhr)
Um nicht auf die Weboberfläche angewiesen zu sein, muss man einen Git-Clienten auf dem Rechner installieren. Es gibt einen von GitHub selbst, mit dem habe ich aber keine Erfahrung.
Ich nutze immer TortoiseGit, das integriert sich ins Explorer-Kontextmenu.
TortoiseGit erfordert zusätzlich noch den eigentlichen Clienten Git for Windows, aus irgendwelchen Gründen möchte TortoiseGit aber zuerst installiert werden.
Mit TortoiseGit installiert sich bei Standardeinstellugne auch das SSH-Programm PuTTY mit dem Schlüsselgenerator PuTTYgen. Den benötigen wir zur Erzeugung des Schlüsselpaares für GitHub (s.o.).
Die meisten Key-Typen sollten funktionieren, sicher bin ich mit bei RSA und Ed25519.
Nach dem Klick auf Generate muss man ein bisschen die Maus im leeren Feld bewegen und dann erscheint der öffentliche Schlüssel. In dieser Form komplett markieren und bei GitHub einfügen funktioniert.
Den Private Key speichert ihr (am besten passwortgeschützt) an einem sicheren, aber zugänglichen, Ort.
Nebenbemerkungen:
- Wenn man den Public Key in einer Datei speichert ändern sich die Kommentare leicht, da muss man dann darauf achten, nur den eigentlichen Schlüssel zu kopieren und evtl. noch "ssh-rsa" oder was eben der Schlüsseltyp ist davorzuschreiben.
- Falls ihr den SSH-Key nicht für GitHub sondern mit OpenSSH (z.B. bei direkter Nutzung von Git for Windows ohne TortoiseGit) einsetzen wollt, gibt es oben im PuTTYgen-Fenster unter Conversions die Option, den Schlüssel ins OpenSSH-Format zu exportieren.
Jetzt könnt ihr euer lokales Repository anlegen. Dazu wird das Repository von GitHub geklont (clone).
Man kopiert sich also die SSH-URL vom Repository.
Im Kontextmenu (rechtsklick), idealerweise da, wo euer Code liegen soll, wählt ihr "git clone" aus.
Im folgenden Fenster ist die SSH-URL schon eingetragen, wenn sie grad in eurer Zwischenablage war, und als Ordner ist der aktuelle Ordner\PieAncientEurope ausgewählt. Das kann an dieser Stelle noch angepasst werden.
Dann wählt ihr noch "Load Putty key" aus und wählt eure Private-Key-Datei. Die ist damit für dieses Projekt gespeichert und ihr braucht nur noch das Datei-Passwort eingeben, um Änderungen am Repository auf GitHub zu legitimieren.
Pull
Später braucht man das Repo nicht jedes Mal neu zu clonen, ein einfaches "pull" reicht aus, um die letzten Änderungen herunterzuladen und automatisch in den lokalen Stand zu mergen. "fetch" stellt eine Alternative dar, wenn ihr euch anderweitig um den Merge kümmern wollt. Es ist empfehlenswert, regelmäßig zu pullen, wobei das durch die geplante Branchstruktur relativiert wird (dazu später mehr).
git fetch lädt neue Daten vom Remote-Repository runter, integriert die aber noch nicht ins Arbeitsverzeichnis.
git pull entspricht git fetch; git merge HEAD
Geändert von Flunky (22. Oktober 2021 um 15:16 Uhr)
Ich denke es spricht nichts dagegen, in einem einzelnen Repo (meinem) zu arbeiten. Du kannst aber natürlich auch einen Fork (eine Kopie des aktuellen Stands) in dein eigenes anlegen. Das hab ich mit keldath gemacht, daher gilt das Repo von keldath für meins als "upstream".
Wenn du in meinem Repo mitarbeiten willst ist die wichtigste Regel, Features in eigenen Branches zu entwickeln. Also wenn du ein Feature angehen willst, wechselst du zuerst auf den "main"-Branch, pullst dir die letzten Änderungen und legst basierend darauf einen neuen Branch an, zu dem du dann wechselst.
Immer, wenn du irgendwas sinnvolles programmiert hast (sei es ein kleiner Bug gefixt, ein Teil des Features implementiert...), committest du die Änderungen mit einem entsprechenden Kommentar. Spätestens am Ende der Programmiersession sollte dann auch gepusht werden. Geht ja auf deinen Branch, wo nur an diesem Feature gearbeitet wird.
Wenn das Feature dann fertig ist, stellst du einen Pull Request ein und ich merge den Featurebranch in den Mainbranch.
Genauso können auch Hotfix-Branches angelegt werden, die entsprechend kurzlebiger sind.
Wenn wir mal soweit sind, wird auch ein Release-Branch angelegt, auf den nur stabile Versionen und gegebenenfalls Hotfixes gemergt werden.
Neue Dateien zum Repository hinzufügen
git add setzt neue Dateien unter die Versionskontrolle. Die anderen Befehle interessieren sich nur für Dateien, die irgendwann mal geadded wurden. Änderungen committen
git commit nutzt du, um Änderungen zu versionieren. Hier ist eine Commit-Nachricht zwingend erforderlich, typischer Weise schreibt man da rein, was man gemacht hat oder welches Issue bearbeitet wurde. Konflikte bearbeiten
git merge führt verschiedene Arbeitsstände (zwischen Branches oder Repositories) zusammen. Das funktioniert überwiegend automatisch, manchmal muss man nacharbeiten.
Hochladen (push)
Mit dem Befehl "push" werden alle eure lokalen, committeten Änderungen auf das GitHub-Repo übertragen. Dabei werden die Arbeitsstände auf Konflikte überprüft, was vor allem durch zwischenzeitliche Commits von anderer Stelle auftreten kann. In so einem Fall muss zuerst gepulled und die Arbeitsstände lokal zusammengeführt werden. Das ist fast immer kein Problem, der automatische Merge funktioniert allerdings nicht bei Binärdateien oder wenn dieselben Zeilen modifiziert wurden. Dann muss man von Hand nacharbeiten. Daher haben Kompilate wie die DLL auch eigentlich nichts im Repository verloren. Ich würd sie dennoch hochladen, damit immer ein Arbeitsstand verfügbar ist für die, die nicht selbst kompilieren können.
Geändert von Flunky (22. Oktober 2021 um 15:29 Uhr)
Das Visual-Studio-Projekt liegt unter PieAncientEurope\PieAncientEuropeVI\CvGameCoreDLL\Project.
Eventuell funktioniert es nur, wenn man erst Visual Studio startet und das Projekt von dort aus öffnet.
Die Datei Makefile.settings_bak müsst ihr lokal in Makefile.settings umbenennen und dort die Pfade zum Toolkit, PSDK, einem vollständigen CvGameCoreDLL-Ordner mit dem Boost-Ordner und optional eurem lokalen Mod-Ordner für das automatische Kopieren einer kompilierten DLL eintragen.
Weil das bei jedem anders ist, steht Makefile.settings nicht unter Versionskontrolle.
Geändert von Flunky (22. Oktober 2021 um 15:23 Uhr)
Zitieren
