Lektion 1: GitHub lesen können — ohne zu programmieren

Erklärlektion· ca. 35 Minuten · Lernziel: Du orientierst dich in einem GitHub-Projekt, beurteilst dessen Gesundheit und Vertrauenswürdigkeit und lädst Releases sicher herunter.

Warum GitHub dich betrifft

Fast alles, was du in diesem Kurs kennengelernt hast, wohnt auf GitHub — der grössten Plattform für gemeinsame Software-Entwicklung. Wer GitHub lesen kann (nicht: programmieren!), findet Werkzeuge Monate vor den Zeitschriften, erkennt Blender vor dem Download und holt sich Hilfe an der Quelle. Das ist die Kernfähigkeit fürs Weiterlernen nach dem Kurs.

Die Landkarte: Was du auf einer Projektseite siehst

• Repository («Repo»): der Projektordner — Code, Dateien, Geschichte. Der Source Code ist das Rohmaterial; als Nicht-Programmierer brauchst du meist die fertige Ausgabe (Release).
• README: die Startseite des Projekts. Gute READMEs beantworten in einer Minute: Was ist das? Für wen? Wie installieren?
• Releases: versionierte, fertige Ausgaben — hier liegen Installationsdateien. Sicherheitsregel: Installer nur von der Release-Seite des Original-Repos (oder der offiziellen Website), nie aus Forum-Links.
• Stars (Lesezeichen anderer Nutzer) und Forks (Kopien zum Weiterentwickeln): grobe Beliebtheitssignale — Beliebtheit ist nicht Qualität, aber tausende Stars bei aktiver Pflege sind ein gutes Zeichen.
• Issues: öffentliche Fehlermeldungen und Wünsche. Deine erste Anlaufstelle bei Problemen — meist hatte jemand deinen Fehler schon (Suchfeld!).
• Commits/Branches: die Änderungsgeschichte in kleinen Schritten bzw. parallelen Linien; Pull Requests sind vorgeschlagene Änderungen. Für dich vor allem als Aktivitätsanzeige interessant.
• Lizenz: was du rechtlich darfst — bei Software meist grosszügig (MIT, Apache), aber der Blick lohnt, spätestens bei kommerzieller Nutzung (die Open-Weights-Lektion aus KM3 lässt grüssen).

Die Gesundheits-Checkliste

Fünf Blicke, zwei Minuten — danach weisst du, ob ein Projekt lebt:

1. Letzter Commit / letztes Release: Wochen bis wenige Monate = lebendig. Über ein Jahr = wahrscheinlich verwaist (bei «fertiger» Kleinsoftware verzeihlich, bei KI-Werkzeugen kaum).
2. Issues-Verhältnis: Werden Fragen beantwortet, Fehler geschlossen? Hunderte unbeantwortete Issues = Betreiber überfordert oder weg.
3. README-Qualität: Verwahrlost oben = verwahrlost drinnen.
4. Ein Betreiber oder viele? Projekte mit mehreren aktiven Beitragenden überleben Lebenskrisen einzelner.
5. Releases statt nur Code? Für Nicht-Programmierer wichtig: Ohne fertige Releases brauchst du Python/Node-Kenntnisse und virtuelle Umgebungen — machbar (die Begriffe kennst du aus den Praxismodulen), aber ein Aufwandssignal.

Sicher ausprobieren, sauber dokumentieren

Der Experimentier-Zyklus für jedes GitHub-Fundstück, aus den Kursbausteinen zusammengesetzt: Backup der betroffenen Daten (KM8) → Installation nach den Download-Grundregeln (KM4) → Test im Experimentier-Ordner → bei Problemen: Fehlermeldung dokumentieren (exakter Wortlaut + Screenshot + was du davor getan hast — genau die drei Dinge, nach denen jedes Issue fragt) → Issues durchsuchen, erst dann selbst fragen → am Ende sauber entfernen (Rücksetzweg) oder bewusst behalten.

Damit bist du autonom: Du kannst jedes neue Werkzeug der nächsten Jahre finden, beurteilen, testen und wieder loswerden — ohne auf Kursaktualisierungen zu warten.

Das kann ich jetzt

• Ich finde mich auf jeder GitHub-Projektseite zurecht — vom README bis zur Lizenz.
• Ich beurteile Projektgesundheit in zwei Minuten und erkenne rote Flaggen.
• Ich habe einen kompletten Experimentier-Zyklus: sichern, prüfen, testen, dokumentieren, entfernen — mein Weiterlern-Werkzeug für die Zeit nach dem Kurs.