Immer wieder werde ich gefragt, wie die Entwicklung von Ham-Tools eigentlich abläuft. Sitzt da einer am Küchentisch und tippt drauflos, bis es irgendwann läuft? Ehrlich gesagt: Am Anfang war es fast so. Heute nicht mehr. In diesem Artikel zeige ich euch, wie ich an Ham-Tools arbeite – und stelle euch dabei das Werkzeug vor, ohne das bei mir gar nichts mehr geht: Git und GitHub.
Keine Angst, das wird kein Informatik-Vortrag. Wer ein Logbuch führen kann, versteht auch Git. Das ist keine Floskel, die beiden Dinge sind sich tatsächlich ähnlicher, als man denkt.
Contents
Das Problem: «Welche Version war nochmal die gute?»
Wer schon einmal an einem eigenen Projekt gebastelt hat – ein Arduino-Sketch für den Rotor, ein Skript für den Contest, eine Homepage – kennt das Muster: Es läuft. Dann ändert man «nur schnell etwas Kleines». Danach läuft nichts mehr. Und die funktionierende Version von gestern? Überschrieben.
Die klassische Notlösung sieht bei vielen von uns so aus:
hamtools_final.zip
hamtools_final2.zip
hamtools_final_WIRKLICH.zip
hamtools_final_WIRKLICH_neu.zipIch gebe zu: Genau so habe ich früher gearbeitet. Bei einem Projekt wie Ham-Tools mit inzwischen ADIF-, Cabrillo-, CSV- und EDI-Unterstützung, DXCC-Auswertung, Kartendarstellung und POTA/SOTA-Anbindung wäre das heute Selbstmord. Ein falscher Handgriff und wochenlange Arbeit ist weg.
Was dagegen hilft, heisst Versionsverwaltung. Git ist das Werkzeug, GitHub die Plattform dazu – dort liegen die Projekte gesichert und verwaltet. Beides kostet nichts.
Git in Funkersprache: Ein Logbuch für Code
Die einfachste Erklärung, die ich kenne: Git ist ein Logbuch für dein Projekt.
Jedes Mal, wenn ich einen Arbeitsstand speichere, mache ich einen sogenannten Commit – das ist der QSO-Eintrag im Logbuch. Datum, Uhrzeit, was wurde geändert, kurzer Kommentar dazu. Und genau wie im Logbuch kann ich jederzeit zurückblättern: Wie sah der Code am 15. Mai aus? Ein Befehl, und ich habe exakt diesen Stand wieder vor mir. Nichts geht verloren, nie.
Das zweite Konzept ist der Branch, und dafür habe ich eine Analogie aus dem Antennenbau: Wer eine funktionierende Antenne am Mast hat, reisst die nicht ab, um direkt daran herumzuexperimentieren. Man baut die neue Version daneben auf, vergleicht, misst – und erst wenn die neue besser läuft, wird getauscht.
Genau das machen Branches:
Die grüne Linie ist der main-Branch – die «Antenne am Mast». Das ist immer der stabile, funktionierende Stand von Ham-Tools. Die Version, die ihr herunterladen könnt, kommt von hier.
Will ich ein neues Feature bauen, zweige ich einen eigenen Branch ab (violett). Dort darf ich experimentieren und auch mal richtig etwas kaputt machen – main bleibt davon unberührt. Jeder Punkt auf den Linien ist ein Commit, also ein gespeicherter Arbeitsstand. Erst wenn das Feature fertig und getestet ist, führe ich es per Merge zurück in die Hauptlinie.
Der Ablauf Schritt für Schritt
So sieht ein typischer Entwicklungszyklus bei mir aus:
Die violetten Schritte passieren lokal auf meinem MacBook, die grünen auf GitHub. Konkret:
- Branch erstellen – für jedes Feature einen eigenen. Bei mir heissen die zum Beispiel
feature/llota-importoderfix/adif-export. - Committen – nach jedem sinnvollen Zwischenschritt ein Logbucheintrag. Nicht erst am Abend alles auf einmal, sondern in kleinen, nachvollziehbaren Häppchen.
- Push zu GitHub – der Branch wird auf die Plattform hochgeladen. Damit ist die Arbeit auch gesichert, falls das MacBook den Geist aufgibt oder im Wohnmobil ein Kaffee darüber kippt.
- Pull Request – auf GitHub sehe ich alle Änderungen nochmals sauber im Vergleich, Zeile für Zeile. Bei Teams prüft hier ein Kollege den Code. Als Solo-Entwickler bin ich mein eigener Prüfer – und erwische dabei erstaunlich oft Dinge, die mir beim Programmieren durchgerutscht sind.
- Merge in main – das Feature ist offiziell Teil von Ham-Tools.
Wie das bei Ham-Tools konkret aussieht
Ein Beispiel aus der Praxis: die LLOTA-Integration, an der ich gerade arbeite. Lakes and Lagoons on the Air ist ein junges Aktivierungsprogramm, und Ham-Tools soll die Logs dafür sauber verarbeiten können.
Dafür existiert ein eigener Branch. Dort baue ich den Import, teste mit Beispiel-Logs, verwerfe Ansätze, probiere neu. Der main-Branch – und damit die Version bei euch auf dem Mac – bekommt davon nichts mit. Sollte sich unterwegs herausstellen, dass ein Ansatz nichts taugt, lösche ich den Branch einfach. Kein Schaden, kein Chaos, kein hamtools_final_WIRKLICH.zip.
Getestet wird übrigens nicht nur am Schreibtisch. Der POTA-Workflow von Ham-Tools musste diesen Frühling bei Aktivierungen in Italien zeigen, ob er im Feld wirklich taugt – mit dem IC-705 auf dem Campingtisch statt in der komfortablen Shack-Umgebung. Erst wenn ein Feature auch draussen funktioniert, wo das Internet wackelt und die Zeit knapp ist, kommt es in die Hauptlinie.
Warum sich das auch für dein Projekt lohnt
Jetzt denkst du vielleicht: schön für ihn, aber mein Rotorsteuerungs-Skript hat 80 Zeilen, dafür brauche ich das nicht.
Doch, gerade dafür. Die Einstiegshürde ist nämlich viel kleiner als ihr Ruf:
- GitHub-Konto: kostenlos, private Repositories inklusive. Niemand muss seinen Code öffentlich zeigen.
- GitHub Desktop: Wer die Kommandozeile scheut, bekommt eine grafische Oberfläche, in der Commit und Push zwei Mausklicks sind. Die Befehle aus der Grafik oben laufen dann im Hintergrund.
- Backup gratis dazu: Jeder Push ist automatisch eine Sicherung ausser Haus. Allein das ist den Aufwand wert.
Und wer weiss – vielleicht wird aus dem privaten Repository irgendwann ein öffentliches, und andere OMs steuern Verbesserungen bei. Genau so ist ein grosser Teil der Amateurfunk-Software entstanden, die wir täglich nutzen. Ham2K PoLo liegt offen auf GitHub, Cloudlog ebenso, dazu unzählige kleinere Logger und Tools. Wer mag, kann dort jedem einzelnen Commit zuschauen.
Fazit
Hat Git meine Arbeit an Ham-Tools «revolutioniert»? Solche Wörter überlasse ich den Marketingabteilungen. Aber verändert hat es sie deutlich. Ich experimentiere mutiger, weil nichts mehr verloren gehen kann. Fehler finde ich schneller, weil ich nachschlagen kann, wann welche Änderung reinkam. Und ganz ehrlich: Seit jeder Arbeitsstand automatisch gesichert ist, schlafe ich auch ruhiger.
Wenn du selbst an Software, Skripten oder auch nur an Konfigurationsdateien für deine Station bastelst: Probier es aus. Ein Nachmittag Einarbeitung reicht für den Anfang. Die ersten Commits fühlen sich noch umständlich an – nach einer Woche willst du nicht mehr zurück.
Fragen zur Ham-Tools-Entwicklung oder zum Einstieg in Git? Schreibt mir – ich helfe gerne weiter.
73 de Chris, HB9HJI