Vom Zettelkasten-Code zum Open-Source-Projekt: Wie die Sammlungsdatenbank auf GitHub gelandet ist

Die Sammlungsdatenbank hat in den letzten Wochen einiges an neuen Feldern und einem Karten-Layout bekommen – das stand ja schon im Changelog. Was dort nicht draufsteht: Direkt danach habe ich mich an etwas völlig anderes gewagt, das mich fast mehr Nerven gekostet hat als jedes einzelne Feature – ich habe den Code aufgeräumt und auf GitHub veröffentlicht.

Weil dabei ein paar Dinge passiert sind, die vermutlich nicht nur mir passieren können, dokumentiere ich den Weg dahin mal etwas ausführlicher.

Der Auslöser

Die Idee kam eigentlich beiläufig: Ich wollte im Blog-Changelog auf den tatsächlichen Code verweisen können, statt nur in Prosa zu beschreiben, was sich geändert hat. Also: Repository anlegen, Code hochladen, fertig – dachte ich.

Was ich nicht bedacht hatte: Ein Projekt, das über Jahre gewachsen ist und nie für fremde Augen gedacht war, hat so seine Leichen im Keller.

Was beim Aufräumen alles zutage kam

Bevor überhaupt eine Zeile Code irgendwo hochgeladen wurde, ging es erstmal ans Durchforsten des Projektordners – Datei für Datei, mit der Frage: Wofür ist das eigentlich noch da?

Ein paar Fundstücke:

• Ein Admin-Passwort, das schlicht „admin” lautete. Aus einer frühen Entwicklungsphase übrig geblieben, nie geändert, weil es ja „nur für mich” war. Ist jetzt durch ein zufällig generiertes, gehashtes Passwort ersetzt.
• Zwei alte Testskripte mit fest eincodierten API-Keys (u. a. für einen früheren WhatsApp-Versuch und einen Debug-Helfer). Beide Skripte nutze ich längst nicht mehr – die betroffenen Zugänge sind widerrufen bzw. waren ohnehin schon abgelaufen.
• Diverse „nur kurz zum Testen”-Dateien, die Serverinterna offenlegten (Verzeichnisstruktur, PHP-Konfiguration) und dabei komplett ungeschützt im Netz standen – teilweise seit Monaten.
• Tote Datenbankspalten und Code-Pfade, die nichts mehr taten, außer Verwirrung zu stiften.

Nichts davon war akut gefährlich, solange niemand gezielt danach gesucht hat. Aber genau das ist ja der Punkt: Man weiß es erst, wenn man wirklich jede Datei einzeln durchgeht und sich fragt, ob sie wirklich noch gebraucht wird. Diese Bestandsaufnahme hat am Ende deutlich länger gedauert als das eigentliche „Code hochladen”.

Git für Einsteiger

Ich hatte vorher nie mit Git gearbeitet – Versionskontrolle war für mich bisher: Datei umbenennen, „_alt” dranhängen, weitermachen. (Ja, genau die Sorte Dateien, die ich oben gerade aufgeräumt habe.)

Der Umstieg auf echtes Git war holpriger, als ich gedacht hätte – nicht wegen der Konzepte, sondern wegen der vielen kleinen Stolpersteine: zwei Befehle aus Versehen in eine Terminalzeile kopiert, ein Commit, der nie stattgefunden hat, weil Git meinen Namen nicht kannte, eine Repo-URL mit einem Bindestrich zu viel. Alles für sich genommen banal, aber in Summe ziemlich viel Trial-and-Error für jemanden, der zum ersten Mal git push tippt.

Was mir dabei geholfen hat: Claude Desktop bekam über eine lokale Erweiterung direkten Lese-/Schreibzugriff auf meinen Projektordner. Dadurch konnte ich Änderungen direkt am echten Code durchführen lassen, statt Dateien ständig hoch- und runterzuladen – inklusive dem kompletten Sicherheits-Check aller Dateien, bei dem die oben genannten Fundstücke ans Licht kamen.

Vom privaten zum öffentlichen Repository

Sobald ein .gitignore stand (Zugangsdaten, Logs, alte Testdateien – alles außen vor), ging’s an den eigentlichen Aufbau:

• Ein schema.sql mit der reinen Datenbankstruktur, ohne echte Daten – für alle, die das Projekt für sich selbst aufsetzen wollen.
• Eine config.example.php als Vorlage, aus der man seine eigene Konfiguration ableiten kann.
• Eine README mit Setup-Anleitung, Feature-Übersicht und einem eigenen Abschnitt zu Sicherheitshinweisen – quasi die Essenz aus dem, was ich beim Aufräumen gelernt habe.
• MIT-Lizenz, damit klar ist: Forken, Anpassen, Weiterverwenden ist ausdrücklich erwünscht.

Das Ganze lief zunächst als privates Repository, damit ich in Ruhe alles nochmal durchsehen konnte, bevor es für jeden einsehbar wird. Erst nach einer letzten kompletten Kontrolle (Dateiliste einmal komplett durchgegangen, nochmal explizit nach Zugangsdaten gesucht) habe ich auf „Public” umgestellt.

Das Ergebnis

Die Sammlungsdatenbank ist jetzt öffentlich einsehbar:

👉 github.com/Jungsis-Corner/sammlungsdatenbank

Falls jemand von euch selbst mit einer Sammlung jongliert und Lust hat, sich den Code anzuschauen, zu forken oder eigene Anpassungen vorzunehmen: Nur zu. Ist klar auf meinen eigenen Anwendungsfall zugeschnitten (deutsche Oberfläche, Retro-Computing-Felder), aber als Vorlage zum Anpassen sollte es taugen.

Mein Fazit

Der eigentliche Code-Umbau der letzten Wochen (Karten-Layout, neue Felder, Barcode-Scan etc.) war am Ende der einfachere Teil. Die Aufräumarbeiten davor – jede Datei einzeln hinterfragen, alte Zugänge widerrufen, verstehen, was ein Skript eigentlich tut, das man vor Jahren mal „nur kurz zum Testen” angelegt hat – haben mich mehr Zeit gekostet als gedacht. Aber genau das würde ich auch jedem empfehlen, der ein gewachsenes Projekt jemals veröffentlichen will: Lieber einmal zu gründlich durch jede Datei, als hinterher zu merken, dass irgendwo ein Zugangsdaten-Klartext oder ein „admin/admin”-Passwort mit online gegangen ist.