023
28.08.2021, 14:29 Uhr
joergd
|
Ich schreibe mal auf, wie ich das machen würde. Das ist nur ein Beispiel für das mögliche Vorgehen, bekanntlich führen viele Wege nach Rom. Ich verwende seit Jahren nur noch Linux und Git dann auf der Kommandozeile. Das sollte sich von Windows aber nicht wesentlich unterscheiden. Auch dort würde ich auf der Kommandozeile anfangen. Das ist die Grundlage, darauf basieren dann auch die vielen grafischen Tools. Mit der Kommandozeile bekommt man eher ein Gefühl dafür, was im Hintergrund passiert (meine Meinung).
Als erstes logge ich mich bei https://github.com/ ein. Wer noch keinen Account hat muß natürlich erst einen anlegen. Dann erstelle ich dort unter "Repositories" mit Klick auf "New" ein neues Repository mit folgenden Angaben: - Repository name: CAOS - Description: Cassette Aided Operating System, das Betriebssystem für den KC85/5 - Public/Private: Public - Initialize this repository with: o Add a README file: aktivieren o Add .gitignore: nicht aktivieren (erstellen wir dann selbst) o Choose a license: aktivieren
Eine Lizenz zu wählen, ist für öffentlich zugängliche Projekte eigentlich immer gut (damit andere wissen, was sie damit machen dürfen), fürs CAOS aber vielleicht nicht ganz einfach. Ich nehme als Beispiel mal die MIT Lizenz, damit erlaubt man die uneingeschränkte Nutzung und schließt jede Gewährleistung aus.
Nach Klick auf "Create repository" wird dieses erstellt und gleich in dieses gewechselt. Dort kann man schonmal auf das grüne "Code" klicken, dort "SSH" wählen und sich die URL merken. In meinem Beispiel ist das "git@github.com:joerg-d/CAOS.git" (joerg-d ist mein Github-Account).
Jetzt geht es auf dem eigenen PC weiter (Kommandozeile). Falls noch nicht geschehen, werden die wichtigsten Grundeinstellungen vorgenommen:
Quellcode: | $ git config --global user.name "Beispielnutzer" $ git config --global user.email beispiel@example.com $ git config --global core.safecrlf true $ git config --global core.autocrlf true (bei Windows) $ git config --global core.autocrlf input (bei Linux) |
Nun wechselt man in das Verzeichnis, wo man das Verzeichnis mit dem neuen Repository erstellen will und gibt dort folgendes ein:
Quellcode: | git clone git@github.com:joerg-d/CAOS.git |
"git@github.com:joerg-d/CAOS.git" ist die URL zum Repository auf Github (s.o.). Mit "clone" wird ein exakter Clone lokal auf dem PC erzeugt (in einem Verzeichnis mit dem Names des Repositories). Wenn also Github mal kaputt geht, hat man immer wirklich alles noch lokal auf dem PC (und auch andere, die das geklont haben). Und wenn man auf dem PC aus Versehen alles löscht, klont man wieder neu von Github.
Ich wechsle also ins neue Verzeichnis und sehe mir den Inhalt an:
Quellcode: | cd CAOS dir (Windows) / ls -l (Linux) .git LICENSE README.md |
Da liegt also wie auf Github erstmal nur die Lizenz und die README.md. Zusätzlich gibts noch das Verzeichnis ".git". Da liegen Konfigurationsdaten vom Git, die sind uninteressant. Jetzt kopiere ich den aktuellen Stand des Projektes in das Verzeichnis. Mangels CAOS-4.8-Quellen nehme ich für das Beispiel die vom CAOS 4.7., also kopiere ich folgende Dateien ins CAOS-Verzeichnis:
Quellcode: | CAOS47.INC CAOS47.Z80 CC47.INC CD47.INC CE47.INC CF47.INC EQU47.INC ZSGROSS.INC ZSIBM.INC ZSKLEIN.INC |
Damit wurde das lokale Git-Repository geändert, was man am Status sieht:
Quellcode: | git status Auf Branch main Ihr Branch ist auf demselben Stand wie 'origin/main'.
Unversionierte Dateien: (benutzen Sie "git add <Datei>...", um die Änderungen zum Commit vorzumerken) CAOS47.INC CAOS47.Z80 CC47.INC CD47.INC CE47.INC CF47.INC EQU47.INC ZSGROSS.INC ZSIBM.INC ZSKLEIN.INC
nichts zum Commit vorgemerkt, aber es gibt unversionierte Dateien (benutzen Sie "git add" zum Versionieren) |
Git hat also gemerkt, daß es Änderungen gibt (die neuen Dateien), aber diese noch nicht übernommen. Zur Übernahme (Commit) vorgemerkt werden die Dateien mit "add":
Quellcode: | git add * fatal: CRLF würde in CAOS47.INC durch LF ersetzt werden |
Hierbei erscheint also eine Fehlermeldung. Ursache ist, daß in CP/M Assembler-Quelltexten am Zeilenende wie auch unter Windows ein CRLF steht, unter Linux und Git-intern aber nur ein LF. Normalerweise macht Git das je nach Betriebssystem automatisch richtig. Intern wird immer LF verwendet. Wird unter Windows geklont/ausgecheckt, ersetzt Git die Zeilenenden durch CRLF, bei Linux bleibt es beim LF. Ich will aber auch unter Linux mit einem CP/M-Assembler übersetzen, also auch CRLF am Zeilenende haben. Das sage ich Git, indem ich eine Datei ".gitattributes" im CAOS-Verzeichnis mit folgendem Inhalt erstelle:
Quellcode: | # Auto detect text files and perform LF normalization
* text=auto *.INC text eol=crlf *.Z80 text eol=crlf |
Dadurch wird bei Dateien mit den Endungen .INC und .Z80 am Zeilenende immer und überall CRLF beibehalten, für alle anderen Dateien bleibt es beim Automatismus.
Ein "git status" zeigt nun auch die Datei ".gitattributes" mit an. Diese müssen wir zuerst zum Commit vormerken, danach alle anderen Dateien:
Quellcode: | git add .gitattributes git add * fatal: LF würde in CE47.INC durch CRLF ersetzt werden |
Da gibts immer noch einen Fehler, diesmal wegen der Datei "CE47.INC". Da sind komischerweise im Original Zeilenenden nur mit LF drin. Damit das einheitlich ist, ist es sinnvoll, da auch CRLF draus zu machen. Unter Linux mit:
Quellcode: | sed -i 's/$/\r/' CE47.INC |
Nun können endlich alle Dateien zum Commit vorgemerkt werden:
Der Status zeigt jetzt folg. an:
Quellcode: | git status Auf Branch main Ihr Branch ist auf demselben Stand wie 'origin/main'.
Zum Commit vorgemerkte Änderungen: (benutzen Sie "git restore --staged <Datei>..." zum Entfernen aus der Staging-Area) neue Datei: .gitattributes neue Datei: CAOS47.INC neue Datei: CAOS47.Z80 neue Datei: CC47.INC neue Datei: CD47.INC neue Datei: CE47.INC neue Datei: CF47.INC neue Datei: EQU47.INC neue Datei: ZSGROSS.INC neue Datei: ZSIBM.INC neue Datei: ZSKLEIN.INC |
Nun kann ein Commit erfolgen, die Änderungen (hier die neuen Dateien) werden damit eingecheckt:
Quellcode: | git commit -m 'erster Commit mit Version 4.7' |
'erster Commit mit Version 4.7' ist ein kurzer Kommentar dazu, welche Änderungen mit diesem Commit durchgeführt wurden. Das ist bis jetzt nur lokal auf dem PC passiert. Zu Github übertragen wird das Ganze mit:
Nun kann man sich das Repository auf Github ansehen. Die Quelltexte von CAOS 4.7 liegen jetzt auch dort.
Der nächste Schritt wäre, das Ganze zu compilieren. Auch hierzu gibt es mehrere Wege. Viele werden den Assembler einfach mit ins Verzeichnis mit den Quelltexten kopieren, das Verzeichnis in einem CP/M-Emulator "mounten" und den Assembler dort starten. Ich kopiere also Z80ASM.COM nach CAOS, starte den Emulator mit dem CAOS-Verzeichnis in D: und assembliere CAOS 4.7:
Quellcode: | D: Z80ASM CAOS47/A REN CAOS47.KCC CAOS47.COM |
Anschließend gibt es im CAOS-Verzeichnis im Vergleich zum letzten Commit zusätzlich die Dateien Z80ASM.COM und CAOS47.KCC, wie man am Status erkennt:
Quellcode: | git status Auf Branch main Ihr Branch ist auf demselben Stand wie 'origin/main'.
Unversionierte Dateien: (benutzen Sie "git add <Datei>...", um die Änderungen zum Commit vorzumerken) CAOS47.KCC Z80ASM.COM
nichts zum Commit vorgemerkt, aber es gibt unversionierte Dateien (benutzen Sie "git add" zum Versionieren) |
Mit dem nächsten "git add / git commit / git push" würden die auch auf Github landen. Das sollen sie aber eigentlich nicht, da gehören nur die Quelltexte hin. Deswegen muß Git mitgeteilt werden, welche Dateien ignoriert werden sollen. Dazu wird im CAOS-Verzeichnis die Datei ".gitignore" mit folgendem Inhalt angelegt:
Quellcode: | *.COM *.KCC *.PRN *.LST |
Nach einem
Quellcode: | git add .gitignore |
interessiert sich Git dann nicht mehr für Dateien mit diesen Endungen:
Quellcode: | git status Auf Branch main Ihr Branch ist auf demselben Stand wie 'origin/main'.
Zum Commit vorgemerkte Änderungen: (benutzen Sie "git restore --staged <Datei>..." zum Entfernen aus der Staging-Area) neue Datei: .gitignore |
Wir müssen nur noch die .gitignore-Datei commiten und zu Github pushen:
Quellcode: | git commit -m '.gitignore: Compilierte Maschinenprogramme und Programm-Listings ignorieren' git push |
Damit haben wir CAOS 4.7 fertig im Github-Repository angelegt. Deswegen können wir dort eigentlich auch ein Release erstellen. Dazu "Create a new release" anklicken und folg. ausfüllen:
- Choose tag: 4.7 (neu erstellen) - Release Title: CAOS 4.7 final - Describe this release: (da können z.B. die Neuerungen beschrieben werden) - Attach binaries by dropping them here or selecting them: Da kann das Download-Archiv mit den EPROM-Inhalten hin
Wie das dann alles aussieht könnt ihr euch unter https://github.com/joerg-d/CAOS ansehen (lösche ich aber bald wieder, dient nur als Beispiel).
Nun kann ich ganz normal mit der CAOS-Entwicklung weitermachen: die Quellen mit dem Lieblingseditor editieren, und wie bisher übersetzen. Sobald eine Teilaufgabe abgeschlossen ist, wird ein neuer Commit erstellt und zu Github gepusht.
Für den Anfang sollte das erstmal genügen. Vom langen Text bitte nicht abschrecken lassen. Wenn man das einmal so durchgespielt hat, braucht mal zusätzlich zur bisherigen Entwicklung eigentlich nur noch die 3 Git-Befehle:
Quellcode: | git add * git commit -m '<Kommentar>' git push |
Natürlich geht mit Git noch sehr viel mehr. Haben andere etwas committet, holt man sich diese Änderungen mit "git pull" ins lokale Repository. Mit dem Beginn der Entwicklung an einer neuen CAOS-Version sollte die alte Version in einen Branch ausgelagert werden. So könnte man dann bei Bedarf an der alten Version noch Fehlerkorrekturen durchführen. Andere können mitwirken, indem sie Pull-Requests einstellen oder Fehler (Issues) melden. Vielleich macht es auch Sinn, eine Organisation (z.B. kc85) zu erstellen Dann würde das Repository nicht mehr unter https://github.com/joerg-d/CAOS liegen, sondern unter https://github.com/kc85/CAOS. -- VG - Jörg |